Meeting the Goal of Estimation
When teams start doing Scrum and begin sprint planning, one of the more frequent and emotional conversations is the one about agile estimation. The classic discussion is about whether points or hours are better. But there is a now third option in the mix: a movement called #NoEstimates.
Estimating with points is about relative sizing, a classic agile approach to estimation where developers agree on size without agreeing on time. To drive home the point that the larger the task, the vaguer the estimate, point estimates often use a nonlinear scale, such as a Fibonacci sequence. Even though points are meant to defer a detailed discussion about time, Mike Cohn argues that points are about time anyway, in that more complex tasks take longer.
Time-based estimation, whether in days or in hours, is the classic estimation measure in many traditional as well as some agile projects. When teams estimate in hours, they often still use a nonlinear sequence to enforce the idea that bigger estimates have less precision. Time-based estimates are often easier to visualize, but it can be hard to account for variations among developers.
#NoEstimates (so written because the idea started as a hashtag on Twitter) is an approach that, contrary to its provocative name, does involve estimation, but the estimation is focused on ensuring work is broken down in priority order. You estimate only when you know enough about the work to estimate accurately, Ron Jeffries explains. #NoEstimates also is compatible with Scrum.
Some early advocates of story points, like Ron Jeffries, now favor #NoEstimates. Jeffries apologizes for having advocated points, even though the idea has some value in an ideal world:
There are a number of ideas about how to estimate using something other than time. Points, Gummi Bears, Fibonacci numbers, T-shirt sizes. These were originally invented to obscure the time aspect, so that management wouldn’t be tempted to misuse the estimates. (I know: I was there when they were invented. I may actually have invented Points. If I did, I’m sorry now.)
Regardless of the technique teams use to estimate, the teams that are best at meeting sprint goals in Scrum are the ones who have well-defined stories on the backlog, which they can break down into well-defined implementation tasks. #NoEstimates is appealing to me because it forces that level of thinking before the team makes a judgement about the viability of completing the work, so a #NoEstimates approach (perhaps by another name) seems like a promising way of helping teams meet their spring commitments.
How does your team estimate, and does it meet the goal of estimation? Does your team understand the goal of estimation?
