Measure things

Why does the creator of Mario Bros. enjoy guessing the dimension of random objects?

I heard about this a few months ago, and it didn't surprise me.

I used to think that a measuring tool could only be a physical object. Since then, I learned that an estimate is also a measuring tool.

When planning, agile teams measure the relative size of tasks. This is how they know what features they can ship in the next iteration. I'd be willing to bet that for most teams, these estimates are wrong.

They're so wrong, that I ended up believing that accurate estimates don't exist. But I still went through the motions. It's no surprise they call some of these agile practices "ceremonies".

Guessing is a recipe for disaster. But it feels like that's the only way. You guess "5 hours" and add (an arbitrary) 30%, just to be sure.

Successful software teams measure how effective their measurements are. If you did, you wouldn't be guessing. And you certainly wouldn't use "story points" as a metric.

What I'm about to describe will be familiar to you if you've studied statistics. I wish this would be taught in high school.

If you are measuring time or financial impact, use a range. Two numbers, instead of one. To express uncertainty, describe your confidence level. Or better, agree on a predetermined confidence level for all your estimates. Express that as a percentage.

"With 90% certainty, this will take us between 10 and 20 hours". If you are not that confident in your estimate, expand the range until you are. Assuming that you use 90% as your confidence level, if your estimates are correct, you should be right 90% of the time.

As you get better at this, your estimates become reliable and planning becomes easier. You can take more risks, because you know what to expect. It's like climbing up a ship's mast to see the horizon. You gain visibility into the future.

I hope you found this valuable

I send out an e-mail whenever I publish new content. It's free. No spam. Unsubscribe whenever you want.