Estimating product backlog items is one of the most contentious tasks in Agile software development and Scrum teams often misunderstand how they should apply Story Points when estimating. This article explains how we deal with these misunderstandings at Administrate and outlines our iterative approach to estimating backlog items.
What are the common misunderstandings?
Story Points are directly equivalent to time
Because human beings are used to estimating effort in terms of weeks, days, hours etc. it is easy to assume that Story Points are directly equivalent to time. The truth is that humans are actually not very good at estimating using time, particularly at the outset of a project where actual work can take up to 400 percent longer to complete than estimated (look up the “Cone of Uncertainty”).
What we are good at, is estimating things in relative rather than actual terms. Even if a backlog item is difficult to estimate in terms of time, determining if the effort involved will be more or less than another item in the backlog should be a more straightforward process. As a team progresses through their backlog and more of the items have been estimated, it should become easier to apply relative estimates to the remaining items.
Story Points are measured using the Fibonacci sequence, where the next number in the sequence is the sum of the previous two (i.e. 0, 1, 1, 2, 3, 5, 8, 13 …). We use these numbers because they are easily differentiated and far enough apart to have more meaning when used as an estimate of effort. For example, when faced with having to estimate a backlog item as either a 5 or an 8, the answer will be more meaningful than if the estimate could be any of 5, 6, 7 or 8.
The raw value of the story point is not actually that important - it is the relative values that actually matter. For example, a User Story that is estimated as a 2 should involve twice as much effort as a 1 and be two-thirds as much effort as a 3.
Don’t fall in to the trap of directly equating Story Points to hours. If this approach is taken, too much emphasis is placed on making initial estimates in hours and then converting them to Story Points, which loses the benefit of using an abstract unit of measure. Instead, allow engineers to focus on estimating in relative terms - this way different engineers who have different skill levels and work at different speeds can still reach a consensus on estimates.
You need to thoroughly plan for all of the backlog items in a project at the outset and stick to that plan
Whilst up-front planning is important, it can be counter productive to try to plan an entire project in great detail before it has begun. As mentioned earlier, estimates made at the outset of a project are often wildly inaccurate. However, as a project progresses and those working on it understand the problems in greater detail, estimates should start to fall more in to line with reality. For this reason, it makes sense to refine your estimates throughout the lifetime of a project rather than doing it all up-front.
Detailed planning should be reserved for the backlog items that will allow the team to deliver the next increment of value and items that are further down the backlog should only be given outline estimates. Estimates by their very nature will never be exact, so there is little point in spending too much time estimating those things that you don’t yet know a lot about.
Regular feedback serves as the best driver for determining if you need to change or re-estimate your plan. At the end of each iteration, the team and the Product Owner should reflect on whether the work just completed helps to solve at least a part of the problem and whether the project is heading in the right direction - if it isn’t, don’t be afraid to change the plan. The team should determine if they need to re-estimate their backlog items with every bit more they learn about the problems they are trying to solve.
One person’s estimate is more valuable than another’s
Sometimes teams will make the assumption that the opinion of the most experienced or most technically adept person in the team is the most valuable when it comes to estimating a backlog item. Surely the opinion of the person who knows most about the problem area is the one that should hold most influence on the final estimate? This might be somewhat true if that person actually carries out all of the work involved in that backlog item, but in reality the work will likely be spread across the team
It is important to listen to the expertize of this team member and use that to help understand the exact work that will be involved, but make sure to reach a consensus from across the team.
Don’t assign Story Points to bugs
There is a school of thought which says that bugs should not be assigned Story Points due to the difficult nature of estimating the true extent of a defect. Whilst there is some merit in this argument, the team’s velocity will not take into account the effort that has gone in to fixing these bugs and therefore won’t provide a true representation of the work the team was able to complete in a given iteration.
Again, estimates are just that - estimates. They won’t be entirely accurate, and an inaccurate estimation is more valuable than no estimation at all, particularly when it comes to Sprint Planning. If it turns out that an estimation was inconceivably wrong then talk about it at Sprint Retro and determine how this can be improved in the future (this applies to both bugs and User Stories).
Conclusion
Story Points provide an abstract way of estimating backlog items in relation to each other. They should not be equated to time so that the team does not get distracted by agonizing over exact measurements in terms of hours.
The team should focus on estimating those backlog items that will deliver the next increment of value to the project and receiving regular feedback on each iteration should act as a driver for determining if the plan needs to change or be re-estimated.
Always make sure that estimates are a consensus from across the team and are not biased towards the opinion of the team member that is most experienced or technically adept.
Finally, apply estimations to bugs in order to ensure that the team’s velocity is accurate and to assist with planning.
A final thought
Story Points are not the only measurement used for estimating backlog items. Some teams use t-shirt sizes (S, M, L, XL) and some use dog breeds (Dachshund, Terrier, Labrador, Great Dane). These are much more abstract measurements and reinforce the notion that the value lies in the relative assignment rather than the actual values. Story Points are the most commonly used measurement due to the fact that teams find working with numbers to be more natural.