Your team is humming along, producing sprint after sprint of working code, continually expanding your software application with great features that your clients love. Then one day during a backlog refinement session someone asks, “What’s the maximum length for a user-defined report name?”
You all look at one another and shrug. Then someone says,
“I don’t remember, was it in the user story?”
“Maybe. When did we do it? What sprint?”
“Two sprints back? No, three. I remember it was hot out.”
“Can’t be, we haven’t touched user reports in months. You’re thinking of dashboards.”
“Was the maximum even in the acceptance criteria?”
“No, it wasn’t. I remember we had to ask the product owner during the sprint.”
“So the story won’t have it, even if we do find it.”
“Somebody log in, create a report, and try really long names until you find the limit …”
You’ve just run up against one of the drawbacks to agile methodologies: valuing conversation over documentation means you sometimes don’t write down things that you’ll need to remember much later.
There’s no question that the focus on business value delivery, the elimination of big requirements up front, and decomposition into small demonstrable chunks, are all advantages to agile requirements that can improve a team’s success. But when you’re building a big system over a long period of time, you need more than memory and a pile of completed user story cards as documentation.
A continually maintained functionally organized requirements model bridges the gap between business-oriented user stories and technical design documentation (assuming you’re creating and maintaining those). It can be used by your requirements team for impact analysis, and it can be a crucial part of your trace matrix. With proper linking you can generate metrics around functional test coverage, development by persona, and other measures of your product.
Maintaining a requirements model iteratively does not add a great deal of work to each sprint. And that’s key – requirements are not added to the model until the work is committed to a sprint. During the sprint, the team (usually a business analyst, but on a truly cross-functional team any member should be able to do it) adds the requirements for each item in the sprint to the model. The user story becomes one or more business requirements, the acceptance criteria become functional and non-functional requirements and business rules. The team identifies and documents any additional requirements that weren’t part of the conditions of acceptance – like that maximum field size for report names.
When creating test cases, the team creates links between the tests and the requirements. Even if you work with an IDE (Integrated Development Environment) that automatically links test cases to user stories, you will derive value from linking the tests directly to the more granular requirements. The team will be able to tell immediately if their test plan is not covering part of the functionality. They will also see other requirements related to the functionality that have already been done, and the test cases linked to those. This supports test case maintenance and reuse.
Organizing your requirements functionally makes it easier to find requirements, and allows your requirements team to see new requirements in context. You will be far less likely to specify a new feature that contradicts one you built six months ago if, as you’re analyzing the new requirement, you have a look at the model and see the earlier requirements.
Breaking out requirements by type: functional, non-functional, business rule, business requirement, and perhaps others allows you to trace from most technical/granular up to least. You can look at a top level business requirement and see all of the functionality linked to it that a change might impact.
Isolating non-functional requirements is important because, at least in a Scrum process, many of them are not stated as part of the user story and conditions of acceptance. They are applied to all work by the team as part of standards and definition of done. Likewise, the non-functional requirements in the requirements model should be derived from standards (e.g., your user interface standard, your performance standards) and will change less frequently – unless you’re redoing your user interface, improving performance, or focused on some other area related to quality. What must happen each sprint is linking of new functional requirements to related non-functional requirements.
And finally, business rules should be isolated because they often can change without impacting functionality. Changing the allowed length of that user-defined report name should not mean changing all the code having to do with defining and naming the report – just the validation on its length.
If you’ve scaled your agile process and have more than one team working on the same software, the shared requirements model is a critical tool to help them keep track of the state of the system as they go. Imagine if the team doing the grooming at the start of this blog entry didn’t even do the user story that created the report name function?