Agile Estimation

1. December 2009

People are important

One of the questions that I am asked mostly is about planning and estimation. Therefore a recent question of a colleague led me to today’s episode:

Why do we distinguish story points on users stories and hours on tasks?

The reason is granularity and accuracy and also the relation to people and the efficiency of estimation.

Specifying and estimating the requirements:

  • First we prepare the product vision of our product to be built. This is something like a short essay what the key features of the product are.
  • When we start with the project, we actually specify use cases – but not all of them before we started developing. Only the most important features and only enough to get started. Of course we continue with them over the project
  • Now, we extract user stories. Fine grained “use cases” that build small features that can be implemented. These user stories are linked to the use cases. One user story can be used in multiple use cases to fulfill the use cases requirement. (This is need to for setting up testing)
  • With the user stories that have been dropped into the product backlog, we start estimating those based on story points
  • Based on product backlog user stories and their points and based on the team’s velocity (see below), which is measured in story points per sprint, we take the number of stories that sum up to the velocity and move those into the sprint.
  • Only now the team starts to break down each user story of the sprint into detailed technical tasks that can be implemented. The main difference here is that we have decided that those developers that are most likely (but not necessarily) to implement the tasks should do the estimation. However estimation always should take into account that someone else in the team should be in that range of estimated hours.
  • After all estimations have been done, the hourly total of the user stories’ tasks is compared with the hours of available development capacity (minus some overhead)
  • Only now the team is asked for commitment to the sprint.

Why do we estimate story points first and how is it done?

  • The main point here is that estimation of story points is about SIZE. A story that has three points is three times bigger than a story of of one point. A story of five point is almost twice as much as a story of three points.
  • All story points are estimated by the whole team. As such the points (and therefore the size) are related to the whole team. We estimate the size of the stories for the whole team, so it is not person-related.
  • The teams velocity for a sprint is easily measured: Just take the number of story points that have been performed by the end of the sprint. The average number of the last three sprints make up the velocity.
  • Based on that velocity the next amount of user stories are taken and put into the next sprint.
  • To put it into a nutshell:
    • User story points are size (not effort) only.
    • Points refer to the whole team not an indivual
    • Points can be quickly estimated (we strive to estimative on average in two minutes)
    • Points are used for mid and long term planning

Why do we estimate tasks in hours?

  • As stated further up tasks are technical details that have to be implemented during the sprint.
  • As a best practice and to be more efficient we do not estimate each user story with the whole team. The team distributes the user stories to smaller teams or pairs who then split down the user stories into tasks. The people who take care of this work are most likely but not necessarily those who do the implementation. Thereby the accuracy of definining the tasks, the preciseness of the hour estimation and the commitment is pretty high. We experienced an accuracy of about 5% for the team for a sprint on avarage which is extremely good.
  • To put it into a nutshell:
    • Tasks are tied to Sprints
    • Tasks are estimated on hours to get effort  not size
    • As a best practice we try to let those estimate that are most likely to implement the tasks (though is not a rule)
    • Hours are compared to the available capacity

Commitment

  • Commitment is therefore a two step process
    • The first part of the commitment is when the velocity meets the number of the story points for the sprint. Thus the team feels a realistic setting for the task building and estimation
    • The second part is when the hours are estimated and compared to the capacity
    • ONLY THEN, the team commits.


The above picture shows a close-up of one of our candles.

Trackback URI | Kommentare als RSS

Write a comment