Using Points and Hours for Estimating
Whether one should ever estimate in an agile project is a subject of debate. But if you decide that there is some value to estimating, you have to decide with which unit to measure—points, hours, or something else.
Mike Cohn describes a statistical correlation between points and hours, which means that you can make some reasonable guesses about how many hours an N-point story will take, but there's no guarantee. If your goal is answering the question "Will this fit in a sprint?" both points and hours have uncertainty.
If your team has a consistent velocity, estimation can help you understand how clear your stories are. If you team doesn't have a consistent velocity, neither points nor hours may help you.
Jeff Sutherland states that points are better and more accurate than hours. His main argument is that points tend to smooth out differences between the team and individuals. And point estimation has the added benefit of being quicker.
Josh Kerievsky advocates abandoning both points and and hours and working in variable length iterations. In this approach, the team commits to a number of backlog items, and when the work is complete, the team ships it. For those interested in release planning, the team estimates stories in units of "team weeks" and periodically re-evaluates.
In essence, time is the unit of estimation, but the estimates aren't used to evaluate the success of the sprint. Acknowledging that different things work for different teams, Kerievsky ends his post with "While there will never be one right way to be agile about estimation and planning, you would do well to avoid yesterday's outmoded and highly defective techniques."
Patrick Welsh's post on the Industrial Logic blog makes a point that may resonate with anyone struggling with estimation: Small is the new big. Dividing your backlog into units of work that are small and roughly the same size makes for more predictable delivery.
Without estimation of any kind, it's difficult to understand how effectively you can deliver. It seems that the important question isn't really "how one estimates" but "how stakeholders use the estimates, and whether everyone understands the uncertainty in the estimates." A unit of estimation that makes the uncertainty more obvious is probably the best approach.
How do you estimate? Do you use points, hours, or some other unit? And, how do you use these estimates?
