Assume now that you have been so effective in presenting your project to top business management that they have given your project their full support, and you are eager to move forward. What else do you think you still need to have for your project?
The answer is a good product backlog and, to create this backlog, a good way to capture requirements in the form of user stories, which are called in this case Product Backlog Items (PBI).
Below is an approach we have used to help many teams capture user stories for their product backlog. Given the complexity of some other techniques, it is a small contribution we are making to the Agile community, hoping that you will find it useful, as many people do.
A New Visual Requirements Gathering Process for Agile and Scrum
This two-step process first helps identify the stakeholders and their goals. Then, using a “forest and tree” analogy, it helps gather requirements for users who represent the stakeholders and links those requirements back to the stakeholders’ goals for prioritization.
First Step: Identify the Stakeholders and Their Goals
Identify the different categories of stakeholders of the new software product.
When you first start your project, make an effort to identify all parties who have an interest or stake in, or need for, your software product (see Figure 4.1).
Next, inventory stakeholders and their goals. Identify their goals by asking questions such as “What are your business objectives or goals?” “Why would you need the new software product?” and “How do you measure your goals accomplishment?”
The SMART Rules
There are many ways to help identify goals, but one of them is known as the SMART rules, which we used extensively to help set goals for many teams:
Specific: Everyone will have the same understanding as to what the goals are.
Measurable: We can objectively determine if the goals have been reached.
Achievable: The stakeholders agree as to what the goals are.
Realistic: We shall be able to achieve the goals for the project with the resources we have.
Time-Based: We will be given enough time to achieve the goals.
An example of the stakeholders’ goals and measurements is presented in Figure 4.2.
During this step, you will meet with the stakeholders’ representative users, each in her individual role, to try to understand the needs of some of the users and turn those needs into requirements for the new software product.
Our technique, called “the trees and the forest” and illustrated in Figure 4.3, is visual and easy to use.
Start at the forest, or overall product, level. Ask yourself what your new product should be composed of. In other words, how many “trees” should be in your “forest"?
Next, further divide a tree into its branches (Figure 4.5).
Then, divide the branch into leaves as shown in Figure 4.6.
In addition to going top down like this, you may also ask the users to list all the stories, or leaves, they can think of first, then try to group them together, using this tree and forest analogy to get from the leaves to the branches, then from the branches to the trees, and then from the trees to the forest.
In the same way that the product owner can use the SMART rules to verify the stakeholders’ goals, he and the team can use the CUTFIT rules listed in the next section to verify that their stories, or PBIs, are properly written, ready for the development team to estimate and develop.
There are many ways to help verify that the requirements are well written, but one of them is known as the CUTFIT rules, which we used extensively to help validate the user stories.
Consistent: A consistent requirement does not conflict with another requirement.
Unambiguous: The reviewers of a requirement statement should be able to draw only one interpretation of it, regardless of their role.
Testable: We should be able to create test cases for a requirement. If a requirement is not testable, trying to determine whether it is correctly implemented is a matter of opinion.
Feasible: It must be possible to implement each requirement within the known capabilities and limitations of the system environment.
Independent: No user story (PBI) should be dependent on another user story (PBI).
Traceable: You should be able to link each requirement to a user and to his goals.
A question often asked of us is how someone knows whether she is done with writing a user story, without having to flesh out all the details, as we had traditionally done within the waterfall environment. The answer we usually give is that one can stop writing the story when:
The user cannot decompose that story into more end-to-end stories, meaning stories that touch all the layers of the application.
The team can derive tasks, ranging from 4 to 8 hours, from those stories to start their development work.
When the team can start estimating the point of that story using the criteria-based technique we will be presenting in Chapter 5 to estimate the number of points of the story.
Following is a simple example that illustrates our visual requirements gathering (or elicitation) process, not to show all of its strengths (especially in helping correct errors made with other requirements gathering techniques), but only to show how it is easy to use.
Let’s start with Figure 4.7, which shows the product boundary and its stakeholders.
Next, by talking with the stakeholders, we can identify some of the key goals, as listed in Figure 4.8, which also shows how they can be measured.
By following the technique as laid down in the previous section, we can identify three trees (or areas of interest) for this new software product, as demonstrated in Figure 4.9.
More specifically, the trees in this software product are called user management, room management, and reservation management.
By looking at the “User Management Tree,” we can see that it has two branches, the “New User Management Branch” and the “Current User Management Branch,” as can be seen in Figure 4.10.
Finally, by looking at all the leaves on all the branches, we should be able to list them all as shown in Figure 4.11.
As to Figure 4.12, it is how the software product will look like with all the leaves, all the branches, and all the trees within the forest.
As a result of their prioritization, we can assume that the stakeholders will first want to focus on the user stories that bring in the most value to their company or business unit.
After this decision is made, a story card, as shown in Figure 4.13, can be used to describe some high level tasks that the users would want to perform along with all the test cases ("verify that ....") that should be performed for that user story.
One of the Scrum project team’s most critical tasks is to identify the stakeholders and their goals in order to capture requirements for these stakeholders’ representative users, each in their specific role.
While different approaches exist, we offered here a simple and visual two-step process which all of us can use. The first step is to identify the stakeholders and their goals. The second step is to identify the users who will represent these stakeholders, along with their requirements. We did all of this using a visual technique called the Forest and the Tree approach.
To verify that the stakeholders’ goals are well written, they can use a series of rules called the SMART rules. These rules require that the goal be specific, measurable, achievable, realistic, and time-based, meaning achievable within a given timeframe.
To verify that the requirements (user stories or PBIs) are properly written and ready for development, the product owner and the team can use the CUTFIT rules. These rules require that the story point be consistent, unambiguous, testable, feasible, independent, and traceable.
When asked how someone knows if she is done with writing user stories for release and sprints planning, meaning without having to flesh out all the details, a three-point test was given in this chapter to help make that determination.