Development cost is relative to value

As I have written before, developers can be too cost-conscious, and put too much focus on development cost, i.e. effort. This is a problem when it distracts from understanding business value: good estimates for developing unnecessary software are waste. The trick is to balance the two.

There can be too much focus on cost

Software projects typically face all kinds of uncertainty. Reducing uncertainty about cost is a good thing, because software projects often have a maximum budget, which makes cost a critical success factor. If the project has not achieved its goals before this budget runs out, then it has failed.

Project teams can become fixated on quantifying cost, which seems reasonable because cost is, after all, a critical success factor. The danger is that cost is not the only success factor: a project is unlikely to be a success if it delivers software that no-one wants or that just doesn’t work, even if it’s on-budget.

Too much focus on cost is bad, because of what ‘focus’ means. Development teams and stakeholders have limited time, and have to prioritise. An easy prioritisation mistake to make is to put too much focus on something that is genuinely important, at the expense of other important things. Business value is one of those things.

Business value is not obvious

People - and project teams - tend to ignore things that are hard to understand, and stick to things that everyone does understand. Like the drunk man searching for keys under the streetlight, instead of where he actually dropped them, some teams estimate development effort when they should be discerning business value.

Scrum project teams spend hours each sprint estimating development effort. Meanwhile, on several of the Scrum projects I worked on, there was no meaningful discussion about business value despite concern that the product backlog was not properly prioritised. I sympathise with product owners, because prioritisation is as hard as estimation, and Scrum gives the impression that the product owners should do this prioritisation all by themselves.

The irony is that although software estimation is hard, due to various kinds of bias, we have effective techniques for making good estimates. What we don’t usually have, on software development projects, is an equally good technique for estimating business value. That, and a sense of proportion.

Good estimates aren’t good enough

Good estimates aren’t enough; teams need a proportional understanding of business value. Anyone who has read the Scrum Guide ‘knows’ that work must be prioritised by business value, which, like cost, is an area of great uncertainty. Until you have addressed this uncertainty, estimates have limited value. Even with perfect estimates for the whole product backlog, the value of completing the whole thing remains as uncertain as the stories’ business value.

Scrum projects that work without even the relative business value estimation of product backlog prioritisation are just going through the motions, but missing the point. Nothing will save you from failure, and burning the budget without being ‘done’, if you’re building the wrong thing.

So next time you’re talking about whether to estimate in T-shirt sizes, story points or ideal days, you might be focusing on the wrong thing. Perhaps you should only estimate development effort to the same precision as the business value estimate, and not much more. Of course, working out a constructive way to question the product owner’s request for estimates when he hasn’t prioritised the backlog isn’t going to be easy.