Musings on project management: Points v hours re estimating

Wednesday, February 18, 2015

Points v hours re estimating

You're probably fluent in "hours" -- anyone who's managed to acquire some seniority in project management can speak to hours, think in hours, and reasonably compare one effort to another if given hours.

Fair enough..... But are you also fluent in story points? Or other estimating surrogates? Can you think in one and then think in the other, fluently using each to its best advantage?

Mike Cohn, who wrote a really good book -- perhaps the Bible -- on estimating agile projects, has a posting that tells us to be multi-lingual so we can estimate different horizons in different languages. Or, better said: Use the most optimum language according to horizon.

His recommendation:

Points for the far horizons -- as in several sprints ahead -- and
Hours for the close in stuff, like the sprint right in front of you.

So, what's the rationale here, and is it the right thing to do?

Long term, we tend to look for similar experiences for guidance. Long term it's more like: "Is it bigger than a breadbox; smaller than .... ?" (I actually have never seen a breadbox, but I can imagine a box to hold a loaf of bread -- I learned that expression right out of engineering school, and it's stuck)
Long term, we naturally tend to think in analogies, less so in scalable metrics, so breadboxes and points come from the same modus operandi -- analogies. And, points have the advantage of being easier to add and average than breadboxes.
Long term, we are interested in average performance, albeit with unusual long tail events thrown out because their circumstances are not likely to repeat and thus to include them will distort the average
Short term, we can see from today until tomorrow and it's easy to switch languages and say: That object is going to take X hours to test or to refactor, etc.

Then no less a renown software eminence than Ron Jeffries weighs in with about the same idea: short term, do it one way; long term, do it another. But Jeffries has a larger mission: getting rid of estimating as constituent of software development! Though he also says, estimating isn't going away, so lets make it work for us to get to the real project objective: Value. I can buy that!

Then, related to the long/short term thing, in an email "info item" about estimating, brother Mike goes rogue: OMG! Cohn says: you don't have to do estimating if you don't need to prioritize or if no one is asking for predictions.

This is akin to: If the tree falls and no one hears it, was there a sound?

My comment to this advice: NO! (Strong message follows). A project -- or a personal task -- without estimates is totally blind to the future possibilities and probable outcomes.

Frankly, it shouldn't matter to you who wants (or doesn't want) to prioritize -- everything that is otherwise not governed by the physics of sequencing requires some prioritization -- and every consumption of resource should be considered in the context of scarcity: all things are constrained! There's no "limitless" anywhere.

For more on this general topic -- if you're really a non-believer in estimates -- I refer you to the numerous blogs and twitters on #NoEstimates! A good place to start is here.