Agile’s Dirty Secret
Agile purists sometimes seem very proud of eliminating “requirements” from the software development process. The thing is, they haven’t. They’ve just rebranded requirements as the “product backlog.”
A team can’t successfully build anything without a plan, and that’s what the requ — uh, I mean backlog — is. At Streamline we use three tools to manage the backlog through its entire lifecycle:
- Aha! — a product management tool for capturing and forming ideas and product strategy and refining into features.
- Microsoft Team Foundation Server/Visual Studio — for the granular management of user stories. Because we’re a Microsoft shop, the MS development environment is the best tool for the team to manage their daily work, from user stories to tasks to code change sets.
- IBM Rational DOORS — for the functional requirements model and more granular trace matrix. DOORS is a powerful, traditional requirements management tool that might not seem to fit in an agile world, but in fact serves as the backbone of knowledge about our products.
INVEST in Good Requirements
Scrum teams should not accept into their sprint package any backlog item that does not meet INVEST: Individual, Negotiable, Valuable, Estimable, Small, and Testable. Your process must include opportunity for the team to determine whether each candidate item meets INVEST, and the opportunity for the team to estimate the effort before the sprint is packaged. At Streamline we hold a couple backlog grooming sessions and a couple estimation meetings during each sprint to work on the items for the next sprint. While this draws the team away from the current work, it is critical preparation for the next iteration.
Just-in-Time and Trailing Requirements
When you’re building a complex software application that will continue to evolve over several years, it is important to keep track of decisions about functionality that are typically made during each agile iteration. If you don’t, you’ll be struggling to remember the intended sequence of steps in some process, or the business rule governing choices in a context-sensitive menu months later when you need to make changes.
Before agile, you would have turned to the massive requirements specification. But that’s the thing those agilists are so proud of eliminating. Instead, you’ve got all those user stories and conditions of acceptance on hundreds, maybe thousands, of physical or virtual cards to look through. What sprint was the original story packaged in? Did we do any other changes since then? Did the COAs actually cover this specific business rule that’s not making any sense now, or did we come up with the rule during the sprint?
Even if you maintain good metadata on your digital backlog (like, what area of the application the user story is for), and you are able to search for key words, the completed product backlog is still more like the pieces of a jigsaw puzzle — and if you’re under the gun to package an enhancement you’re not in the mood for games.
At Streamline, we believe in just-in-time requirements and maintaining a living functional requirements model. We manage the product backlog in the traditional agile way — high level features decomposed into actionable user stories with conditions of acceptance. Teams groom and decompose and estimate, and stories are packaged. We only specify enough for the team to know what to do. But here’s where we divert from the agile purists: during the sprint, the team also captures the complete requirements in a functionally organized requirements model. The conditions of acceptance are converted into traditional requirements (“The system shall…”), and additional requirements that the team identifies are also documented. Even if functionality is easy to understand by using the software, so granular requirements are not necessary, business rules can be opaque and are especially important to document.
During each sprint, the team also links their test cases to these requirements so that we can collect metrics on functional test coverage. The model supports a trace matrix that allows us to track from a bug through a test case to a functional requirement, over to a related business rule, and up to the original user story.
This functional requirements model serves as an analysis tool for future requirements. We can see all of the related requirements to the one we’re considering changing, as well as the scope of the test cases, and whether there are any existing bugs. The investment the team makes in the requirements model pays off for the product owner and business analyst preparing features and stories for future sprints.