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.
