Get certified - Transform your world of work today


Keep Your Team Seeing RED

6 December 2007

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 SMART tasks.



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.


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




Tools & Techniques
  • User story cards
  • Planning Poker
  • Story Points 
  • Velocity 
  • Feature burnup chart
Key Roles
  • Business (Business stories)
  • Team (technical, enabling stories)
  • Team along with the business/product owner
  • Team
Key Concepts / Guidelines
  • Write in the format "As a <role> I want to <action> to deliver <business value>.
  • 3 C's of user stories
  • Validation centric 
  • Write validation first (before estimating)
  • Define DONE
  • Create a cross- functional team with active, dedicated business involvement
  • Each work sprint should produce potentially shippable, working product
  • Refactoring

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


Nicholas Cancelliere, CSM, 12/13/2007 1:31:58 PM
User story writing can often be something teams lack skill in doing. We're so used to being task focused (thanks to Microsoft Project), when software teams need to be more focused on story acceptance. I love that you mention Bill Wake's INVEST acronym and the use of SMART goals. I too tell teams to use these as simple litmus tests to identifying well-written stories.

Another one I use are the 3-Ws (WHO is the user? WHAT do they want to do? WHY do they need to do that?), which expands on the format formula "As a role," putting emphasis on the conversation that has to happen.
Piotr Uryga, CSM, 12/17/2007 6:31:57 AM
Links to google docs (invest and smart) seems to be broken.
Anonymous, 12/17/2007 10:29:03 AM
The links Piotr mentioned were corrupted in some way. I fixed them and they seem to be working now. The Google docs interface will ask you to login and may ask you to request access from the documents' author(s). If you encounter further difficulties, please email me directly.
Tobias Mayer, CST,Educator,CSM,CSPO, 12/18/2007 7:23:23 AM
Nice article; very clear. I don't agree with this statement though:
> These points are an indication of how long each story will take. One story point might be eight developer hours or two developer hours...
I do not believe a story point represents time in any way, only relative size. To measure (even indirectly) in developer hours is anti-Agile. If time is measured it should be in team hours or team days. Measuring in developer hours fosters a mindset where it is acceptable for developers to work alone on stories. That concerns me.
Mike Sutton, CSM,CSPO, 12/19/2007 10:26:47 AM
Excellent article - easy to read and understand. Though I think there are far too many acronyms already (not necessary in Scrum, but in IT generally! - there you go!).

There is no mysticism to user stories - they are brilliant in their simplicity, so much with agile and Scrum is about embracing reality. Functional specs and waterfall type requirements artifacts draw us into this illusion that everything is in the document (infact that the document is the application in text!). Which is a barefaced untruth. Very few systems can be so well documented in a domain that must have neglible change. (but because I haven't seen every system nor experienced every domain, I can't say there aren't any).
A user story is a promise to have the 'conversation' (arguably the biggest of the 3 'C's) - an IOU from the PO to the Team.

So the more of these articles that simply state this simplicity, the better IMHO.

I agree with Tobias that story points are a measure of relative size. This is something that many teams (once they have got their heads round stories) seem to struggle with. - even I do sometimes. It is easy to fall back into the commitment seeking delusion of waterfall and take any number from a developer's lips to be signed,sealed and set in stone.

Anyway, thats me done. Great article.
Aniket Mhala, CSM, 12/27/2007 4:33:39 AM
Nice article. Nimesh as you mentioned 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.

I think in addition to these three activities, Risk Management in agile way is also
crucial to a successful project delivery. Risks are related with
RED (requirements gathering, estimation, and delivery) and if we donĪ“ÇÖt manage
it properly despite of having techniques for requirements gathering,
estimation, and delivery then project/delivery may go out of control.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up