Relative Estimating

There has been quite a bit of talk recently about people struggling using story points.  I have heard quite a few people saying they don’t estimate at all and just break down the tasks small enough that they are all essentially the same size.  Personally, I still prefer to use story points and relative estimates to size up a project and then velocity to predict out your burndown.

I think one reason people still struggle so much with using story points is we don’t do a good job making the shift into a relative estimating model.  I wanted to share a few things I have done in the past to help teams make this transition.

Give Plenty of Reference Points

Often we ask a team to estimate something in story points compared to other stories, but we don’t make it easy for them to reference those stories.  We ask them to throw out numbers, and naturally they try to equate those numbers to another set of numbers (hours/days/etc).  If we really want people to give a relative estimate, we need to give them easy access to other stories to compare against.  Instead of asking, is this story a 5, ask is this story about the same as this other one.  In the past I have kept a sampling of story cards of various sizes handy for the team to look through.  If it seemed like the team was relying too heavily on the number, sometimes we would just ask them to pick the story from the examples closest in size to the story in question (the reference cards would not list the story points on the card).  Then based on that we would know what the estimate was.

Another good way to focus on the relativity and not the number itself is trying different planning games.  White Elephant Sizing is a good alternative to Planning Poker that focuses a bit more on relative sizing.  It is also very efficient if you are trying to estimate a large number of stories.  You can also simply try to set a ground rule to eliminate “numbers” the next time you estimate.  Force the team to estimate using reference stories and not numbers.

Stop Using Hours Completely

Sometimes teams struggle because we ask for relative story point estimates at one time, and then go back to asking for hour estimates, sometimes in the same meeting.  It is common practice to continue to estimate in hours when breaking a story down into tasks during the sprint planning meeting.  However, this mixture of measurements can cause confusion.  If we are breaking down stories into small enough tasks, putting an hour estimate on them doesn’t provide much additional value.  In my experience, as long as the tasks are small enough that we can see progress (task completion) on a daily, or at most every other day, basis, that is usually good enough.

Ultimately, the burndown that matters during the sprint is the story point burndown.  We want to see stories getting completed and accepted throughout the sprint, not just on the last day.  An hour based burndown based on tasks can be deceiving because until the story is completed, those numbers could be completely wrong.  We may think there is just an hour of testing left, but find out during that hour we made a huge mistake.  I would encourage you to try not using hours at all and focus on getting stories to done as soon as possible, just using the story point burndown during the sprint.

Stop Worrying About the Past

If you are collecting any sort of “time spent” measurement this could be contributing to the problem as well.  We should be much more focused on what is remaining, not what has been done.  If we are tracking time spent and comparing that to an estimate, then we are putting a lot of pressure on the team to be much more precise in their estimate and start worrying about how much time they are reporting based on what they estimated.  We want the team focused on getting a story completed, not worrying about how much time they spent on it versus what they said they would spend on it.  Just keep the team focused on getting work done, then use yesterday’s weather via velocity to plan forward.  It doesn’t really matter if the team said something would take 8 hours and it really took 10.  What matters is that we know the teams velocity and can use that for planning.  However, if we track the actuals versus estimates at all, it sends the message that we care about it, no matter how much we say you don’t.

Hopefully those thoughts will give you some ideas on how to improve estimating.  I think the larger message is that the less emphasis you put on estimating, the better result you will get.  The more your try to “perfect” it, the more anxiety and worry it will cause and your results will get worse instead of better.

Comments on this entry are closed.

  • New blog post. Struggling with relative estimates, try these tips! #agile #storypoints #estimating #in http://t.co/VrgZ4vV3

  • How do you decide how to price a project to the customer if you don’t convert the estimates to hours at some point, and don’t care wether the estimates are accurate or not?

    • You would use your velocity (average number of story points completed per iteration).  That is how you convert estimates to duration, but you don’t do it on an individual story basis.  So if you have an entire backlog that all together has an estimate of 500 and you know your team’s velocity is 20 with 90% confidence intervals at 15 and 25, then you know that, with 90% accuracy you will will be done with the entire backlog somewhere between 20 and 33 sprints.  Usually your 90% confidence numbers will be closer than that, but that’s the general way to do it.  Mike Cohn has a range calculator on his website you can use to calculate those (http://www.mountaingoatsoftware.com/tools/velocity-range-calculator) and this technique comes pretty much straight from his Agile Estimating and Planning book.

    • Also, a point of clarification, it’s not that I don’t care if an estimate is accurate or not, it’s more that I’m going to make them be accurate by definition.  I’m also going to stress accuracy over precision, it’s better to be “roughly right” than “exactly wrong”.  I’m not going to get worried about the fact that you said Story A would take 3 days and it really took 5.  However, because I’m using velocity and not the hour/day estimate, I’m now by default going to assume that any other story you said would take 3 days is likely going to take 5 as well.  So instead of asking a team how long every story will take, we instead ask them to put the stories into buckets of similarly sized stories, then observe over time how long on average items in those buckets take for the team to complete.

%d bloggers like this: