Focus on the Most Challenging Parts of Your Project
The topic of estimation will likely start a (perhaps heated) conversation in a group of agile developers. People often debate which of three approaches to estimation makes the most sense. But the question of points versus hours versus (the inaccurately named) #NoEstimates approach ignores the far more important question of "Why do we want estimates, anyway?"
We estimate to make decisions. An estimate can answer the question, "When will this be done?" But estimation has limits, and trying to estimate too precisely in an agile project is wasteful.
Estimates can help with planning. In the short term, having an estimate can help a team understand if the backlog for a sprint can be delivered with reasonable (not heroic) effort.
In the longer term, estimates can help product owners and business stakeholders understand how to realize a project vision and how to coordinate parts of a project better. The flaw in the argument about points versus hours is that they are two different problems and reqire two different approaches.
Estimation of what the team will do in the next sprint can be based on a good understanding of the problem; if you are starting a sprint without a clear understanding of what you will do, there really isn't a good way to make any reasonable prediction anyway. Neil Killick explains that focusing on what you need to do is more useful than assigning point estimates and measuring velocity:
From the team’s point of view, I believe it is far more valuable to get better at breaking down stories JIT [just in time] (and only JIT – any earlier is potentially wasteful) to be as small as possible (or, at least, as is practically possible) than to “increase velocity”.
Focusing on what work you need to do and validating that the tasks are likely to fit into the sprint gives you a way to measure progress. By driving the backlog by priority, you can better deliver what is valuable to the business.
During early planning, when stories are vague, it can still be useful to talk about sizes of stories, what Killick calls implicit estimation: For the product owner to cost the item, she just needs to ask the team if it is understood or needs breaking down.
While the phase #NoEstimates causes those who are planning projects to recoil in fear, it really does seem to be a way to focus on the most challenging part of project and portfolio planning—by breaking a goal down into incremental parts.
Does your backlog have well-defined tasks on it?
