Dev targets: measuring business value

Typically, dev targets are based on functionality delivered. This depends heavily on having very specific requirements – how do you define “done”? Its much harder than it sounds. What if the functionality is delivered but with major bugs? What if (when) the requirememt change halfway through the sprint – is that shifting the goalposts?

There is a better way. The product owner can assign “value” points to each story, the same way that developers assign “cost” (aka complexity) points. The points can be relative rather than absolute.

The sprint goal can then be framed as: “Deliver business value of X points”. If the requirements change, no problem. If the released code has a bug, it’s value can be deducted from the sprint total. (Fixing bugs can be given a value – the same as for new features).

Have any teams out there tried this approach?

Leave a Reply