There’s much disagreement among software practitioners about how to capture requirements. Some argue in favor of lengthy, detailed documentation. With equal vigor, others argue in favor of simple tools like user stories. What should you do?
There are valid arguments on both sides. Detailed requirements documentation can supply levels of insight that are hard to capture any other way — at a price. The documents will be complex and labor intensive. They are often hard to understand and difficult to maintain as requirements change.
User stories, being simple and fluid, can be easy to grasp. Any user story can be read and understood in isolation. The down side is that the stories can be difficult to stitch together. Many people will have a hard time seeing the big picture representing how the software elements fit together.
You need a story roadmap.
Stakeholders and end users need to comprehend both the big picture view and the user interface details. System designers and developers need a simple and effective way to capture the system requirements. Here’s how to do both — create a roadmap.
I favor the user story approach because I believe the stakeholders and end users can more readily relate to the resulting requirements. However, the stories need to be written and presented in a hierarchical fashion as follows:
Level 1 – Business goals: Why is the project being done? What are the desired business changes and outcomes? Put the goals at the top of the roadmap so you can keep them at top of mind. Goals must have business value and must be measurable. How will you measure how each delivery matches the expectations?
Level 2 – Stakeholders: Who are the people that can facilitate the desired outcomes? Who can contribute to the goals? Who are the people that will be most affected by the software? Separate the stakeholders and end users into groups based on roles.
Level 3 – Needs: For each group, how can the target group contribute to or obstruct the desired outcome? This will help in defining stakeholder and end user priorities.
Level 4 – Themes: Now that you’ve defined goals, people and needs, begin the process of showing what the software has to do. What are the business activities or software capabilities that would support the needs of the stakeholders and end users? For each theme, what are the minimum marketable features?
Level 5 – Epics: For each theme, what are the user activities that need to be supported by the software? These are business activities not point-and-click actions. The epics will be divided into user stories small enough to be implemented within a sprint.
Level 6 – Stories: For each epic, what are the user actions that need to be supported by the software? This is the lowest level. User stories will be implemented during sprints.
Over the course of several blog posts, I’ll elaborate on these levels. Hopefully you’ll conclude that user stories are a superior way to capture software requirements — when they are defined in a hierarchical fashion.
photo credit: espresso marco via photo pin cc
[The next post in this series is available here.]