10 Tips for Better Story Estimation

The foundation of predictable delivery is to make a commitment to an iteration of work using story estimation. In order to make a commitment, delivery teams need to estimate how much work there is and determine whether that work will fit within the iteration timeframe.

So, how do you make sure you’re doing a good job with story estimation?

Let’s take a look at some story estimation methods that can be used by teams, as well as some tips for making the estimation sessions more productive.

What is a Story Estimation?

First, let us come to a meeting of the minds. All estimations are wrong. There are methods for calculating the error in estimation in the mathematics of combinatorics. If this is of interest in your planning practice you might start with mean squares of deviation, but most people can agree that the estimation is going to be wrong and use a heuristic to account for the error. My favorite is to assign a risk to each estimate and apply a buffer for the risk. This is not an exact science and leaves room for interpretation, but it does give the consumers of the estimate the encoded information that the estimate is wrong.

Story Estimation Accuracy:

Consider the level of estimation and how accurate it really needs to be. At the high-level planning stages when trying to decide on which feature to build when, errors in effort have a really high tolerance. If a feature is going to bring an annual return of a million dollars as long as the estimated cost of development is well below $2.5 million on an expected 10-year lifetime, who is going to quibble over a couple $100K?

Story Estimation Tips:

Things to consider for story estimating:

1. Use at least four values during the session. There is the law of diminishing returns to consider, but if there are not enough values then unlike things will get clumped together. Example: if you are using the Fibonacci series to conduct story estimation for a two-week sprint, use at least 1, 2, 3, and 5.
2. Give your team an out if they just don’t know. So, include infinity or at least a really high number.
3. Let the team doing the work conduct the story estimation before they commit. You may have conducted story estimation from a release planning exercise but you should re-estimate the work during iteration planning just before the team commits. Even a day later there may be new information that changes the estimate from yesterday.
4. Everyone on the team gives an estimate. This gives an opportunity to discuss gaps and make sure different points of view are covered.
5. Set a maximum story/feature/epic size based on the time boundaries. If you are portfolio planning and your time horizon is infinite, ignore this tip. In all other cases, break work up to meet the time boundary.
6. No Zeros. Just discussing the work takes time, so if you find you have a lot of really small stories or tasks, try clumping them together and then estimate.
7. No averages or numbers not on the scale. Story estimation is a way of educating and informing decision. Get the team on board.
8. Break up items that exceed the maximum. If you get infinity or something too large for your time boundary, add risk mitigation or spikes to gain more understanding.
9. No distractions during story estimation. There is nothing worse than the lead developer playing on his cell phone during the discussion only to ask for a re-cap before he can show his card.
10. No bribes. Bribing by the technical team, product owner or scrum master undermines the whole process and can lead to saw tooth release burn downs.

Story Estimation Methods:  

I am using the term “work item” to describe the item being estimated. Depending on the estimation level it could be portfolio-level initiatives, epics, features, stories or tasks. The meeting facilitator likewise could be one of several roles including the scrum master for a single delivery team and the product owner is the person representing the work item and has decision-making powers.

Story Estimation Affinity Grouping:

1. 1. The meeting facilitator sets up a board with the agreed estimation scale across the top and lanes for work items.
   2. The product owner reviews the first work item, providing background, persona/customer details and how it fits into the overall goal.
   3. The team discusses the work item along with how it will be implemented
   4. The meeting facilitator asks the team where the work item should be placed on the board.
   5. After discussing all work items for the session, the team reviews the board and agrees that the items are in the correct lanes
   6. The product owner decides whether to accept the work items at that level. I have had a product owner say, “I am not wasting two points on that; let’s remove that story.”
   7. The team agrees on how to handle items that are too large for the time boundary.

Story Estimation Planning Poker:

1. 1. The meeting facilitator passes out poker cards with the agreed scale.
   2. The product owner reviews the first work item, providing background, persona/customer details and how it fits into the overall goal.
   3. The team discusses the work item.
   4. Each team member pulls a card and places it face down on the table.
   5. The meeting facilitator says something like ”1, 2, 3, show.” or some other method to get all the cards turned at the same time.
   6. The team members turn their cards over. If everyone is in the same room it is fun to show your card by placing it on your forehead. Differences in the estimates are discussed and agreement is reached.
   7. The meeting facilitator groups the estimate-complete work items by estimate value.
   8. After all estimates are complete the team discusses each group and moves the work items to the correct group if necessary.
   9. The product owner decides whether to accept the work items at that level.
   10. The team agrees on how to handle items that are too large for the time boundary.

Story Estimation Rock, Paper, Scissors:

1. 1. The team agrees on hand signals for the work item scale.
   2. The product owner reviews the first work item, providing background, persona/customer details and how it fits into the overall goal.
   3. The team discusses the work item.
   4. The meeting facilitator says something like ”1, 2, 3, throw” or some other method to get all the hand signals displayed at the same time.
   5. The team member shows their hand signal. Differences in the estimates are discussed and agreement is reached.
   6. The meeting facilitator groups the estimate-complete work items by estimate value.
   7. After all estimates are complete the team discusses each group and moves the work items to the correct group if necessary.
   8. The product owner decides whether to accept the work items at that level.
   9.  The team agrees on how to handle items that are too large for the time boundary.

Conclusion

I hope this gives you some great ideas for story estimation! Even if you have been using one of these methods for a while, you may want to introduce a new one and see if that produces a more effective estimation session. Have fun with your guesses.

What other methods have you used for story estimation?