Estimation, and Incentives

Estimating sucks, doesn’t it? I mean, sitting through those sprint planning meetings is, easily, the worst part of the job, right? Or wait, maybe those endless discussions about what exactly a story point is, those, are the worst part of the job. Or maybe trying to figure out whether you should switch to T-shirt instead of story points, maybe that’s the worst part.

/via http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/ID/2388/How_do_you_estimate_your_Business_Analysis_or_IT_project_work.aspx

Spend any time in product/development circles, and you’ll run into (a lot of?) people who wear their loathing for estimation as a badge of honor, who swap horror stories in hushed tones, and reflexively glance over their shoulders when they do so. What’s more, there is a bit of an implicit assumption that estimates are all just Dartboard Games anyhow, because, in the end, you’re just guessing…

Hyperbole?
Yes.
And also no, because there is definitely some truth to the above. You see, at the simplest level, this is all about intent, about what you’re trying to get out of the process.

You should be estimating because

1. 1. It forces you to analyze the problem. After all, you can’t estimate in a vacuum, you need to know what you’re estimating, and how you’re going to deliver.
2. 2. It helps to set goals. Once you have a clear picture of the problem (and solution), estimating helps you figure out how much of this you’re going to tackle right off the bat
3. 3. It clarifies choices and tradeoffs. When you’re figuring out the things you are going to tackle, you need baselines that allow you to make choices. The combination of stakeholder wants, and your estimates — this is what allows you to make reasoned decisions around tradeoffs.

In short, estimating is how you go about managing the scope of your project(s).

The deeper point being made above is that each of the above ensures that incentives are aligned across the team. Analyzing the problem, setting goals, coming up with solutions, and knowing which ones to work on first, well, these are things that everybody on the team wants to do, right?
(I’m ignoring politics here, where you might want other teams to fail. Because…let’s not go there, okay?)

If, on the other hand, you estimates to figure out how much work to assign to people (because maximal utilization. Ugh.), then you are just setting yourself up for gamification, right? Overestimation, rigging, slow-rolling, etc. — incentives are now misaligned, and that is never a good thing.

So yeah, go ahead and estimate — for the right reasons — and make sure that everybody on the team has bought into those reasons!