By Nimesh Soni
True project success can be summed up in one acronym: RED (requirements gathering, estimation, and delivery). Each of these key activities is crucial to a successful project launch.
Requirements Gathering
In Scrum, we write user stories to capture a project’s ever changing requirements. Because project needs fluctuate, Scrum doesn’t consider requirements gathering to be a one-time task. Instead, Scrum focuses on the incremental unfolding of requirements. The work is decomposed and captured at different levels in varying levels of detail during the project. At each level, the work is broken down into smaller, more manageable pieces of work.
Product backlog (PB): High-level capabilities and features are captured as user stories. The PB is the repository of all the work that needs to happen during the project.
Sprint backlog: The team identifies the user stories that will be worked on during the current iteration, or sprint. Each user story is decomposed further into tasks.
User stories should be validation-centric. The team needs to identify and write down the validation conditions for each user story. The story should not be closed until these validation conditions are met satisfactorily. As Ron Jeffries mentions, user stories have three critical components (the 3 C's of User Stories): cards (physical medium), conversation (discussion surrounding stories), and confirmation (tests and validation that verify story completion).
Keeping the INVEST acronym in sight can also help agile teams write better stories. A user story should be:
Independent:
A good story should stand on its own.
Negotiable:
A good story is negotiable. It is not an explicit contract for features; rather, details are co-created by the customer and programmer during development. A good story captures the essence, not the details.
Valuable:
A user story should be valuable to the business.
Estimable:
The team should be able to gauge the size of a story.
Small:
A good rule of thumb is that a user story should not be more than eight to sixteen hours of effort.
Testable:
The story should include validation criteria.
When writing individual, detailed tasks under each user story, teams should focus on writing SMARTtasks.
Specific
Measurable
Achievable
Relevant
Time-boxed
Estimation
Once the requirements are captured as user stories in the product backlog, the business will want to know how long it will take to develop the product and when it will be delivered. Estimation is done in two stages: at the individual user story level and at the sprint level (velocity).
The team assigns story points to each user story. These points are an indication of how long each story will take. One story point might be eight developer hours or two developer hours, depending on the team’s estimation scale. One way to calculate these point estimates is by using planning poker. User story-level estimates are usually done at sprint zero (release planning); they also might be done during sprint planning for each iteration.
Accurate estimates can be achieved through:
- A better understanding of user stories. A better understanding allows team to write clear user stories with "just enough" detail to enable the team to have a conversation with the business (customer) at a later date. Having the dedicated and active involvement of the business will help the team to understand and write better stories.
- Clear identification of validation for each user story. The validation should be written before estimation. Having validation clearly defined with the user story will make it very clear to the team what effort is involved for the story and when the story can be closed.
- Active involvement of the business. Having the business involved at all stages (sprint zero/release planning, planning for each sprint, and sprint review) will enable the team to have proper priorities for each sprint. The business will also be there to clarify any user stories that might confuse the team.
- Cross-functional teams. As Mike Cohn mentions, "planning poker brings together multiple expert opinions to do the estimating. Because these experts form a cross-functional team from all disciplines on a software project, they are better suited to the estimation task than anyone else" (Agile Estimating and Planning by Mike Cohn). Having a cross-functional team enables the team to provide more accurate estimates.
- Planning poker: Using planning poker with a cross-functional team will ensure that you get accurate estimates.
- Clear definition of done: Clearly defining what must be completed before the team can say a user story is “done” helps the team provide accurate estimates.
The second level of estimation, sprint level estimation, is a “progressively elaborated” technique. As the team moves from one work sprint to another and closes various stories, it soon can determine its velocity: a measure of how many story points the team is able to close within a sprint. Based on the estimates and known velocity of the team, it is possible to forecast different dates within the release plan and predict how many sprints will be required to complete the project. Feature-level burnup charts can also help teams track their progress at the release level and provide more accurate answers as to when the product will be delivered.
Delivery
One promise of agile is "potentially shippable product increment" (Mike Cohn) at the end of each iteration/sprint. During each iteration, the Scrum Master (SM) should ensure that the work the team committed to do during that sprint is what the team actually delivers.
- The SM should ensure that the team understands the user stories and provides accurate estimates.
- Once the team commits to a unit of work (and is in a sprint), the SM should make sure that the team is focused only on the user stories that are within the current sprint.
- During the sprint, the SM should also ensure that the team is focused on the sprint work (and only the sprint work). He/she should eliminate any impediments that might be blocking the team’s progress.
- The SM should maintain the task burndown chart and story burnup charts, along with the team’s velocity calculations.
Along with these tasks, I also used the spikes in the sprint burndown charts to gauge the quality of the estimates. We also added a dashboard report that was posted on the sprint wiki page and updated regularly. This one-page dashboard report lists the goals of the sprint, and the status of each in terms of red, yellow, and green, where green signifies on track/completed and red symbolizes off-track. This dashboard report also lists any known impediments/issues and status on each of them (open or closed).
By continually focusing your team on RED (requirements, estimation, delivery), you’ll be better able to keep your project in the green.
The RED Grid
| Requirements | Estimation | Delivery | |
| Tools & Techniques |
|
|
|
| Key Roles |
|
|
|
| Key Concepts / Guidelines |
|
|
|
