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?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s