The Backlog Estimation Snail Pace Anti-Pattern

Have you noticed your estimation meetings lasting hours with only a few items estimated? Do you think it is impossible to get an estimated backlog with 3 months of work in it?

Hey, developers. It’s called an estimate. No one is going to stab you if you if it isn’t perfect. You won’t even be stabbed if it is completely wrong. Seriously.

Over analysis of potential backlog items during estimation meetings is a disease. The worst part of this disease is if your team is suffering from this disease, it may very well require a developer-ectomy to cure the team. More on that later.

PlanningPoker.com explains this issue well:

“…, everyone should remember that at some point additional discussion does not lead to improved accuracy. The goal in planning poker is not to derive an estimate that will withstand all future scrutiny. Rather, the goal is to be somewhere well on the left of the effort line, where a valuable estimate can be arrived at cheaply.”

Get it? The point of estimation sessions is to provide estimates. Completely understanding how to implement the idea represented by the backlog item is not a necessary outcome of this discussion. After all, the work may never actually occur. In fact, if the hard decisions are made from the estimate data, many of the items will never be executed.

If you still need convincing that you do not need to understand the work in depth to estimate it, read these books. After reading them, come back to this post for tips on how to influence your team to just get on with it, already!

• Blink : The Power of Thinking Without Thinking
• The Wisdom of Crowds

All that said, here are some techniques to get your estimation meetings back on track.

1. If 1 developer consistently bogs down the discussion, send ’em to the movies for at least 3 sessions. The team will reach a new equilibrium and when the prodigal child returns, the team will re-educate him with new behavior. We are kinda like software users that way, we only know what we want after we’ve seen it.
2. Use planning poker.
3. Use planning poker.
4. Use planning poker.
5. If estimate numbers vary by only +- 2 values, average the numbers, record the estimate, and move on.

   For instance, here is a set of estimation numbers by a team of 5 people using Fibernacci numbers: 5, 5, 3, 8, 5

   In this case, 5 is the middle number and both 8 and 3 are only one value in the set away from 5. Average the values and move on. The estimate for this backlog item is: 5.2.

   If the numbers are 5, 5, 2, 8, and 5, then the team discusses the reason the estimates are so far apart. Specifically, estimators 2 and 8 both get an opportunity to explain their position on their estimate. Perhaps they know something the others don’t.

   Re-estimate and move on.

6. Allow no more then 3 rounds of estimation. At 3 rounds, if the numbers are still off, average them and move on. Even if the numbers on the estimate are huge, that’s fine. What it means is the product owner needs redefine this item in a clearer way and re-submit the item to the team at a later estimation meeting. Alternatively, using the numbers of the failed estimate in #5 above, one user holds to a 2. Even after averaging this value in, we get an estimate of 5. Is there genuine difference between an estimate of 5 and a 5.2? Not worth worrying about.
7. Have an audible timer that sounds every 2 minutes. Trigger it to begin counting at the each failed estimate round. When it goes sounds, cards come up. Period. Everyone must estimate when the timer sounds, even if someone is still talking. As soon as estimates are within tolerance, record the estimate average and move on.

These techniques really can help if you are stuck in Snail Pace Backlog Estimation Hell. Some of them may sound a bit harsh until you take a moment to total up the salaries in the room. DO you have any idea the amount of money spent per minute for a meeting with your development team? You should, but that’s another post.