Tuesday, January 22, 2013

Story Points are only one third of the reason for estimating


“One’s destination is never a place, but rather a new way of looking at things.”
From: Miller, H. (1957). Big Sur and the Oranges of Hieronymus Bosch

Assigning some Story Points to a User Story may seem like the point of agile estimation; however in my eyes it just signifies the end of the process. 

For me the goals of agile estimation are to build a shared understanding in the team of what the story is and to build team consensus around what the rough estimate in Story Points should be.

The journey that the team goes through to come up with the estimate, is more important than the number that is assigned at the end of the process. Sure the assigned estimate assists with planning, however the knowledge that the team gains during discussion will help with their understanding of what they are delivering, why and how they will go about it. I often hear discussions on topics such as: user needs, business value, design, potential new User Stories, testing approach, development approach, how this User Story fits into the Epic, which are all valuable.

Here is a brief summary of the benefits that the team gain by going through an agile estimation process.


Assigning Story Points to each User Story supports



  • Grooming – identify stories that are large / candidates for splitting, identifying inefficiencies such as splitting an 8 pointer into two 5 pointers – should we do it as an 8 pointer to save overall time?
  • Sprint planning – roughly creating a sprint backlog based on average velocity.
  • Sprint planning – switching User Stories of equal Story Points in/out, up/down priority.
  • Release planning – using the combination of average velocity and story points of remaining stories to provide a rough view of our status.



Discussions build a Shared Understanding, which supports



  • Grooming – effective ways of splitting a User Story into multiple User Stories.
  • User Story Planning – splitting user Stories into a set of tasks that will work for the whole team.
  • Development – design ideas, implementation approach, testing approach, etc.
  • Identifying issues – such as impediments, dependencies, etc.



Using consensus to arrive at the Story Points supports



  • Sprint planning – with a stable average velocity and consensus on the Story Point of each User Story, there will be less second guessing of what to pull into the sprint.
  • Commitment to delivering the Sprint Backlog – consensus around the estimate, leads the team owning the sprint commitment. i.e. “it was my estimate, so I will push to finish the story within the sprint”.