Estimate... Less

crystal_ball Estimate can be like gazing into a crystal ball, is there a better way?

Agile is about speed, right? Then why do we waste so much time estimating?


I was at a customer engagement two years ago and the team wanted to utilize a super-simple estimation process that only involved 6 T-shirt sizes: x-small, small, medium, large, x-large and epic. At the time I was enamored with poker-style estimation and was fervently utilizing the latest and greatest tools to implement that style. My problem with their sizing style was that it wasn’t granular enough for my tastes. I argued that with only five effective slots you couldn’t predict future velocity accurately enough. It took a little convincing but I talked them into using my style and we did fine, no complaints at all.

Well, that was two years ago. Since then I've had the pleasure of working with some really smart cookies in the agile world and I've learned a few more things. One gent at my current engagement is a strong kanban practitioner and his point of view on estimation is pretty extreme: Don't.

His teams estimate EVERYTHING at one single story point. On the other hand they spend a little extra time doing their best to scope stories to more or less the same amount of work in each one. His theory is that on average, it all works out in the end. I agree with the last part, but I’m betting that when you factor in the extra work to same-size the stories he isn’t saving as much time as he thinks he is.

His theory kinda makes sense, though. I can see where he's taking a stance that all estimation is guess-work anyway, so why sweat it? But in my mind, he's swinging the pendulum a little too far the other direction. There is value in some sort of rigor around your estimates. After all, the 80% in Pareto’s 80/20 rule is still important.

My current practice is to have my teams quickly throw stories into a small (1 point), medium (3 points) or large (5 points) category with x-large (8 points) reserved for the real monsters. This is fast, easy and causes absolutely no debates about size. We recently estimated a backlog with 40 stories in it in less than an hour. During the course of grooming (you are holding separate grooming sessions, right??) we utilized Rally’s Estimation Board to quickly toss stories where they belong. Rally did the tedious job of assigning the correct story size to them and we were done. Super simple.

Is this as accurate as spending longer to get finer-grained estimates? No, of course not, but I don’t believe the increased accuracy is enough to justify the increased time, effort and confusion (”Wait, what did 8 points represent?”) that a heavier process would carry with it. Keep in mind part of the theory of making this work is that over the long term your errors in underestimating things will balance with errors in overestimating others. Velocity, regardless of how rigorous, is nothing more than a guess anyway. And anything from changing customer desires to your market’s financial health can change things up in an instant anyway.

At the end of the day you can’t be agile if your weighed down by a hundred nit-picky little rules and processes and B.S. like that. Keep things fast and lean, keep the good Mr. Pareto in mind, make your estimate and then go code something.

Helicopter Scrumming
Dancing With the Chaos Monkey


No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Monday, 25 October 2021
If you'd like to register, please fill in the username, password and name fields.