Blog

Planning Poker is an incredibly useful consensus based estimation tool that has become a household word in Agile shops around the world. Personally I love it - when it is used correctly. However, as I have participated in estimation sessions across several different projects and teams, I have noticed three common mistakes that team leaders are making. One mistake takes away from the efficiency of planning poker, and the other two compromise the integrity of the estimates. All are easily avoidable.

The first two mistakes arise when the team leader misunderstands the difference between estimated hours and estimated “bigness”. The last mistake arises when the team leader gets too granular in the estimation process. Remember, in planning poker, we estimate at both the story level and the task level. When estimating stories, we estimate in “bigness”, or relative effort. A story that is estimated at a 5 is slightly more than twice the effort of a story estimated at a 2. Each story can then be broken further down into tasks. Tasks are estimated in ideal hours. That is, a task that is estimated as an 8 will take approximately 8 man hours to complete. (OK, technically an 8 means that it will take more than 5 hours but less than 13, but that is a topic for a different blog…)

Mistake #1
The team leader presents the team with a series of user stories, and instructs the team to estimate each story in ideal man hours instead of bigness. This is usually accompanied with some explanation of how the project is rather small and doesn’t warrant breaking it down into tasks. The problem here is that by definition user stories are high level descriptions of what the user wants the application to do. Applying hours to a high level story is wrong because it is trying to apply a granular estimation unit to a broad estimation item. Estimating user stories in hours gives you a false sense of accuracy because you are applying a precise measurable unit (hours) to a level that is not as precise. What if you wanted to know how far it is from Fargo to Minneapolis?  If I told you that it was approximately 235 miles from Fargo to Minneapolis, that would be a decent estimate. Of course, there are many different possible starting points in Fargo, and even more possible ending points in Minneapolis. It could actually be 220 miles, or it could end up being 250 miles. But 235 is still an accurate estimate because we don’t expect it to be that precise when measuring in miles. Now what if I told you that it was 14,889,600 inches from Fargo to Minneapolis. 14,889,600 inches is equal to 235 miles. But because I am presenting it in a much more precise measurement, it creates an illusion of preciseness. Think of it this way - the more broad the estimation item, the more broad the estimation unit. And who ever told you that there is such a thing as a project that is too small to be broken down into tasks? They were lying to you.

Mistake #2
The team correctly estimates the user stories in “bigness,” but then the team leader takes a predetermined budget and allocates a proportion of the budget to each user story based on the bigness estimate. This time we usually hear some excuse about how the client only had X to spend, and we have to fit the project into that budget. OK, I understand that clients often work on fixed budgets, especially in the current economy. But trying to force an application into a smaller budget tends to create, well, crappy applications. And crappy applications end up costing the client more in the end, between support cost and lost opportunity cost. Instead of forcing the entire application into the predetermined budget, what we should do is use the estimates to figure out how much the client can afford. By prioritizing the user stories with the client, the project manager should be able to give them a reasonable estimate of what can be done for the budget given. This also helps the client plan for future budgets, giving them a reasonable estimate of what the entire project will cost.

Mistake #3
The team correctly estimates the user stories in “bigness.” And the team lead correctly moves on to breaking the stories down into tasks and estimating each task in ideal man hours. Unfortunately, they do it for every single user story. Hove you ever been in an estimation meeting that takes eight hours? I have. There isn’t enough pizza and Mt Dew in the world to make meetings like that fun. Breaking every singe user story down into tasks and estimating the tasks may be fine for small projects (like two or three user stories), but for larger projects, we are creating more work than we need to. And again, it gives us an illusion of a level of preciseness that doesn’t exist. Instead, after the user stories are estimated, pick a representative sample of stories and break them down into tasks that can be estimated into hours. If you have 25 or so user stories that range in “bigness” estimates from 2 to 20, pick four or five of the 8’s and 13’s and estimate them. And then take the story with the smallest hours per bigness ratio, and apply that ratio to the non-estimated tasks. Add the hours for all of the tasks together (estimated and non-estimated), and you have the lower range of your estimate. Then take the story with the largest hours per “bigness” ratio, and apply that ratio to the non-estimated tasks. Again, add the hours for all of the tasks together, and you have the higher range of your estimate. Remember, when providing estimates at the initial estimating session we are trying to be accurate, not precise. A ranged estimate of overall work is more accurate. I can honestly say that when estimating projects this way, I cannot remember a time when the final project cost has not fallen somewhere within the initial ranged estimate. Talk about accuracy!

Estimation tools, like planning poker, are only as good as the way that they are used. Look out for these three common mistakes, and your estimation sessions will yield much better results!