Fallacy of Time-based Estimates

I know a guy incredibly fond of estimating development effort for a ‘scrum’ team in hours. Because, apparently, it’s the best tool to increase developers performance.

Ouch. On so many levels. For so many reasons. As the science of engagement screams in pain while dying, let’s just repeat: ouch.

Of course, there are some arguments against the practice. That no two developers share the exactly same knowledge of the product. That no two developers have the same experience. That, ultimately, we learn and grow by failing. That, maybe, for some reason, we have this team-based tool, called story points, which could make more sense. Because ‘this whole scrum thing’ is all about teams, and so on.

It’s a big no, apparently.

And this guy is actually right! Yes, you can use time-based estimates to evaluate each individual developer’s performance! Yes, it will work! For a price, but let’s just leave it to the side.

On the other hand, it takes some deliberate effort.

First, during the planning session, you have to split all the tasks at hand between individual developers. Simply because, my hour will never equal your hour – which works for every single pair of individuals in the world.

Second, you force each of the developers to precisely estimate the level of effort. It may take up to one full day per two-weeks sprint. A money well spent, apparently!

Third, immediately after the sprint you invest some time to assess each individual’s performance and provide immediate feedback. Failing to do so means no learning occurs, hence people never ever improve.

This guy I know fails on all three.

Which is a good thing after all. Their estimates are rubbish, but as long as nobody *really* cares about them, they’re just fine. Yes, the client will complain for a while – but then they’ll become used to it. Just burning some more money sprint by sprint, oh well.

And yet, it’s not the worst outcome ever!

The worst thing would happen if this guy I know would start exercising his power on the time-based estimates. Because every sane individual involved would just quit. Immediately.

There’s another scenario though. If you were an engineer and was mercilessly persecuted for every time your work log exceeded your estimate, what would you do? That’s right. Increase the estimates. Sure, you’d be bored as hell quite a lot – but safe! Long enough to find another job without quitting immediately.

Story points were created for a reason. Use them. They make sense.

Opinions are my own and not the views of my employers, customers, or clients.

Failed Agile Transformations ebook

Learn how to spot, avoid, and FIX them!