Editor's Note: This post was recently expanded on in the article, How Devbridge uses Lean Requirements
Capturing software requirements is a messy business. For years, the prevailing logic has been to throw some poor soul into the trenches and task them with the responsibility of documenting complex requirements in time-consuming and cumbersome Word templates. The countless hours invested are often justified by the assumption that the resulting documents will clearly articulate exactly what the final product will look like. In reality, this approach often results in documents that are fraught with gaps, misinterpretations, and inaccurate assumptions in a format that is not easy to comprehend.
But let’s say that your organization always writes perfect documentation. How long does it take you? The fundamental issue with this approach is that this activity often takes hundreds of hours of effort to create documents that don’t produce any tangible value for your business. That is a serious amount of waste in an otherwise lean process. The traditional requirements process is bloated and overweight. It’s time to lose that weight and get your requirements lean.
In order to improve the requirements gathering process, we need to understand how software development differs from other forms of construction.
Unlike building a house, the costs to create something demonstrable, and change direction based on feedback, is relatively low. This means that you can leverage rapid prototyping to validate designs and technical integrations while keeping development costs low. More importantly, because we often don’t know what we want until we see it, it’s important to validate our assumptions early and often.
We also know that, because there is a limit to how many stories a team can work on at one point, the number of fully defined requirements a team needs in order to get started is also low. This means we can focus our efforts on defining requirements for the immediate future, while reducing the effort spent on future roadmap features - meaning software requirements can be defined using a just-in-time approach.
We also need to appreciate that software requirements have a shelf life. Because software can change so frequently, requirements stuck in a product backlog can quickly become outdated or invalid. It is important to keep your backlog lean, concise and relevant. Don’t be afraid to delete irrelevant stories in your backlog—if it’s important, it will return.
The reason traditional document-based requirements fail is because they are not optimized to take advantage of these differentiators. The fundamental purpose of the requirements gathering process is to to create an atmosphere of shared understanding on requirements between users, designers, developers and stakeholders. With traditional document-based requirements, this is rarely possible because the only person who ever truly understands the requirements is the author. Put simply, requirement documents promote Agile anti-patterns that prevent businesses from making great products.
But don’t despair! By identifying and eliminating inefficiencies in the requirements gathering process, your requirements will start to become lean.
First, we need to prioritize conversations and collaboration over documentation. This means we have to get our users, designers, developers and stakeholders in a room to discuss product requirements.
Next, we need to do away with time-consuming Word documents and replace them with concise, self-contained stories. The best method is to use markers and Post-it notes. This approach forces you to keep requirements simple and small - if it can’t fit on a Post-it, then it needs to be broken down into smaller pieces.
Lastly, but most importantly, create a shared level of understanding around your requirements. This is achieved by discussing and prioritizing your backlog as a group. Make sure everyone understands the business value, development effort and dependencies between each story. Agree on on your release goals, identify stories that enable that goal, and start building a release plan.
As soon as your first release starts to take shape, identify the quickest and cheapest way to validate your assumptions. Leverage tools like wireframes, mockups, rapid prototypes and technical spikes to improve your ability to make informed decisions as a team. On any team, you are only as strong as your weakest link.
With your team’s newfound shared understanding, they will make decisions quicker, deliver value to your business faster and build better products for your users.
For globally distributed team members, you can leverage product management tools like JIRA to add structure to your backlog, coordinate releases across multiple teams, and provide visibility into your team’s performance.
Additionally, where requirement documentation is required for governance, compliance or audit purposes, JIRA can be used to auto-generate requirement documents and traceability matrices using the information stored in the tool. This approach effectively cuts the document creation process down to minutes.
We’ve leveraged lean requirements for more than 200 clients, from venture-backed startups to Fortune 500 companies. It’s a validated process that has proven to be more effective, cheaper and faster than document-driven requirements. Requirements gathering might be messy, but that’s where we are happiest. Ask us how we can help your organization get lean today.