Estimations, a blog from the past

As part of my previous work at HP, I had been working at defining the approach to preparing and estimating features and user stories in one of my client’s projects. Here these stories are prepared through the early discovery events and progress through demand to the development teams. This post describes the estimations that were performed along this journey.

At the early discovery phases T-shirt sizes are used. The T–shirt sizes is a first guess. The word guess being appropriate. It is based on the feeling for effort, complexity and uncertainty in the story. This is a very early estimate and is used to provide input into the business level release planning. This is useful in providing a feeling for size and begins the initial planning at product or release level. It is a “handful” type of measure.

In some other client organisations the use of the term ADU is applied. An ADU, or Agile Development Unit, is a scrum team for one sprint, with support. This is used to being to understand the amount of resource that will be required. In this case ADUs are bought, and then work can be tailored to fit, a form of cutting your coat according to your cloth.

T-short and ADUs are the first stage of estimating. These are both size and not duration estimates and it makes sense to have some benchmarks that can be used to baseline these measures. This is a form of learning from your experience as sizing stories becomes a question of comparison against known experience. The issue here is how to get started with new teams who have no built up experience. Basically you simply have to guess, which is what an estimate is.

At this point we have an estimate that is not based on a great deal of analysis, but is about relative sizing to previous experience. This allows us to update release plans with the latest estimated work. Based on the priority assigned by the business through the product owner, we now start elaborating the features into user stories.

The next measure of story points is taken by the elaboration team during the cross team sizing process. This includes contribution from the architects and the scrum teams. This is useful for planning of releases. See the article about story points and hours below to explain why this is less useful in terms of planning for an individual sprint.

Comparison between these two stages of estimation is useful. I would examine them and see if there are any unexpected relationships between the various estimates for a story. This means a misunderstanding is present.

Be aware of false precision, for instance in table 1 the values assigned imply too much precision. Table 2 is expressed in a more realistic manner.

Table 1: Too much implied  precision Table 2: This shows a range of estimation mapping

Note that the ranges overlap. This is because the story points are meant to be accurate in large samples and less so as individual measures. See the link about use of story points in planning. When I say that we can look for misunderstandings at this level it means we can look to see if the business sized a story S and the grooming sized it 15. This indicates that we have a difference in understanding and the next step is a discussion about it.

During sprint planning we now move from story points to hours. We need to understand if we are using real or ideal hours? Typically a team will estimate in ideal hors and then translate to real hours using a conversion factor. To learn this factor we should measure the planned hours against the real hours as the sprints progress. It is of course crucial that a team’s time is protected if they make commitments to delivery. This is an area where micro management can destroy the productivity of a team, achieving the opposite of what the good intentioned command and control manager was trying to achieve.

We see that story points are a bell curve distribution of hours. They are used for estimation and are the unit that team velocity is measured in.

Also note that a story point is up to a team to define. It should be based on relative sizes of stories with understood benchmarks from experience. Story points are useful for planning purposes in the release plan. They are good at planning how much work can be done in 6-12 sprints, for instance.

Please note that if you wish to learn more about this subject the very excellent book “Agile Estimating and Planning” by Mike Cohn is recommended