Stop doing estimates? Yes you can!

An interesting session of the Ale2011 is from Angel Medinilla, about the easy way to stop estimating.

Here are my thoughts after attending the session.

The topic originates from a quite simple concept: doing estimates needs time, which is a costs. If they are not needed, they should be considered a waste, to be eliminated, as David J. Anderson stated as well, some times ago.

His finding is that the estimates are actually not needed and he explained why.

This is my short way to come to that conclusion (not necessarily the same as was presented in the session by Angel).

Estimates are, normally, considered useful because they let us "forecast" how much can be delivered within a certain, generally short, period of time.

Well, that's not what a Product Owner really want. What is needed, actually, is not just a short term "forecast", but rather a long term "projection": a reliable release plan. And that plan can be obtained by the teams who know their velocity (usually in term of number of story points per sprint).

But, wait a moment. What if we try to get this projection just counting the features instead of the sum of their estimated size (story points)? It would be like just giving to all the stories one story point.

The fact that the story sizes may be of different sizes doesn't matter so much.

I guess that a statistician would say something like: let's just count the stories released in the past sprints, and we have an unbiased estimator of the velocity of the future sprints. It's true if the sprints are “regular” enough (i.e. the story sizes are equally distributed over the sprints) and the average of the velocities doesn't change over the sprints.

However, beside the above long-winded statement, we may just consider that it is ok also for another reason. The stories are actually small, so though counting stories (instead of summing their estimated size) will introduce a bias, that bias would be small as well.

So I am almost convinced but... wait a moment!

What about the other outcomes from the estimation activity? The conversation on the scope that you have while estimating, say, playing poker planning game?

A "mainstream" opinion is that estimation permits a conversation about the scope, giving the Product Owner important feedback about the possibility of splitting stories, clarify their scope, or modify their priority.

However stopping doing estimates could be still reasonable. Sometimes there is no need to discuss so much and so on... because may be they are perfectly clear to everybody, (and there is still room for a conversation when splitting in sub-tasks)

That could work, at least for a while, but something can change: perhaps there will be new team members, or the product may change as well, or even the customer needs may change. So in all this case, estimation can be a good exercise to let the team gel, and let emerge critical issues.

Anyway, this is just my idea about the session, and I can't remember everything from it, so if I misinterpreted the meaning, or skipped some important parts, I apologize.

Back on topic... nothing is forever. Every context is different from another, so what is good sometimes, sometimes it is not.

If during a retrospective the team suggest skipping estimation, we know that it could be perfectly reasonable and consistent even for the Product Owner, so we can give it a try... and then check.