One of the most frequent complaints I hear when I work with agile teams is about the lack of good product requirements. In an overzealous rush to have ‘working software over comprehensive documentation’, many teams have abandoned traditional product requirements documents. However, having not introduced an effective alternative, they have really only succeeded in creating re-work, waste and delay. Requirements continue to be a major bottleneck in getting software projects off to an efficient start. If requirements are not sufficiently well-defined before development begins then potentially everything downstream from that point will be a waste in the lean sense – incomplete work (inventory), re-work, and defects. How do we set up an approach which is non-waterfall – all requirements must be fully defined before the project moves forward – but which gets us ‘development-ready’ requirements that enable development teams to begin executing as soon as the first feature is properly defined?
First, let’s talk about the characteristics of well-defined requirements, then we will discuss a workflow that gets requirements into this state as quickly as possible so that development teams can become productive. Some of the key qualities attributable to good requirements are:
- Completeness. The requirement is fully stated with all necessary context information, like use cases, diagrams, and dependencies.
- Precision. The requirement is stated concisely and objectively. It is subject to a completely unambiguous interpretation.
- Consistency. The requirement does not contradict any other requirement and is consistent with any source material for the requirement.
- Testability. The requirement is written in a way that its implementation can be validated through testing.
- Traceability. The requirement is traceable to business needs as stated by the customer or stakeholders. The requirement should be traceable to other project artifacts.
Too often development teams struggle with one-line product requirements definitions that leave team members to make too many assumptions, or having to guess. Forcing teams to make multiple trips back to product owners to clarify requirements is not agile, it is highly wasteful. Scrum masters should treat this problem as a project impediment, and push hard with the appropriate people until the information is forthcoming.
The next thing we need is a requirements-level workflow. I can think of several reasons why this is valuable:
- We need an approach to requirements creation that is consistent and repeatable
- The organization needs to be clear about the basic steps to get a requirement into the ‘Defined’ state – one from which user stories can be developed, and from which sprint-level planning can begin.
- The workflow ensures there is no ambiguity about the state of development of any individual feature, and provides a framework for tracking and reporting the status of all features in a release.
A generic workflow might look something like:
If we wanted to have a complete separation of focus on feature definition vs. feature realization workflows then we might adopt something like:
To apply this to sprint planning, we sort the release back log and place all of the Defined features on the top of the stack. ‘Defined’ means development-ready requirements, and sprint planning should be able to proceed with any features in the defined state.
As part of release planning, teams will be working to get enough features into the defined state so that development can get underway. One definition of a ‘Defined’ feature might be:
- Feature has a detailed description
- An architectural assessment has been made – requirement decomposed and allocated to various subsystems
- User stories have been created, and story size estimates made
For tracking progress in the effort to get features to the defined state, a simple Kanban-like chart helps:
This helps to visualize bottlenecks in the process and to ensure the effort is properly resourced. This approach can also be applied as the ‘Portfolio’ level – for all projects that the organization has underway. This can bring clarity to where resources should be focused to optimize feature development throughput. WIP limits can be imposed to prevent overloading of one part of the organization or another. Consider the following distribution of requirements across various stages of the lifecycle:
The numbers in each bucket are requirements. For those requirements that are at the Defined stage or beyond, we should have a total story points estimate. Thus for example if the 20 requirements in development between various releases amount to 400 story points of work, and the 80 Defined requirements require 1000 story points, then there is little point in adding more requirements to the front end of the work flow – where they can potentially actually slow down throughput. In this case development is the bottleneck and the organization should consider some rebalancing of resources to increase overall throughput.
As the release backlog takes shape it might begin to look something like:
If the team has a velocity of say, 20 points per sprint, then in this example we have enough work to keep the team going for at least 2 sprints. Getting the remaining features to the Defined state continues as an ongoing process. A snapshot of a properly groomed release backlog shows us which features can be pulled into the sprint planning process, which ones need further analysis to get to the defined state, and which ones need a basic discussion about whether they should be in-scope for the current release.
In the waterfall model, development work would wait until all features were fully defined. With an agile approach, work should commence as soon as the first feature is defined.
The key piece of advice offered in this chapter is to make the up-front investment to get requirements at least mostly right. This approach is completely aligned with the lean concept of eliminating waste. Grinding through a project with partially-completed features, incorrectly specified features, or with teams simply guessing what to build is a colossal example of waste. Agility requires both discipline and focus. Robust requirements management is a fundamental agile practice.