When you’ve got five software products managed by five product managers, how do you know that they’re all using the same scale when they assign business value?
You don’t. At least, not if you don’t pay some attention to calibrating across the organization.
The other day we had a lively discussion as we looked at completed user stories from our various backlogs and the business values that they’d been assigned. Participants included not only the folks in backlog management roles (directors, managers, and business analysts), but also scrum team members and folks from sales, IT, and client services. It was a fantastic opportunity to show these non-development team members that engineers do want to deliver value!
Nobody in the room knew all about all of the products. But once we’d presented the fundamentals of how business value is used in scrum and a way to evaluate a story, most everyone reached similar values on stories that they understood. We explained our existing scale (zero to three hundred points in ten point increments), and then we suggested some criteria:
- What percentage of existing clients want it?
- Is it for the primary user persona?
- Has it been validated through customer development?
- Is it sizzle or steak?
- Is it primarily to help sales close deals?
- Is it a technical change that will retain existing clients?
Then we presented a series of examples and asked the group to assign value (see the image above). For some, consideration of the number of impacted users was a revelation. For others, abstracting business value by not somehow tying it to revenue was pointless. And for a few, accepting that solving our own problems, like improving deployment or fixing the logo on the home page, has no business value was really tough to swallow. Nonetheless, everyone left with a clear understanding of what those numbers mean on our work items, and the product management team is going to do better at calibrating their value assignments with their colleagues’. That’s a win.