Back in February 2008, I was part of a class with Jeff Sutherland to become a CSM (Certified Scrum Master). During that class, we found ourselves tasked with completing a series of 3 minute sprints and delivering the most value after 3 sprints. Through that task, I devised a simple approach to come up with a computed business value (CBV) effectively in a quick way that you may find useful to add to your sprint planning efforts.

Why: To limit discussions about which item in the backlog is the most valuable to spend time on. Also, it provides a measure  for sprint over sprint comparisons that can provide feedback on the team’s progress. It can provide an effective response to questions that associate sprint velocity to team effectiveness.

What: So the basic premise of the idea involves coming up with two numbers for each item in your sprint backlog.

1. Item Complexity: Rated from 1-7, similar to Story points, and in my case, where the team takes items no bigger than 5, I just use SPs
2. Business Value: A number from 100 to 500, in 100 point increments (although this range could be adjusted any way you see fit)

Team members are charged solely to rate the item’s complexity. Product Owners are charged solely to rate the item’s business value. Because each side of the equation is not subject to the other person’s bias, the final number will remain essentially pure. This should never add any significant time to a sprint planning session, because the PO already knows the business value or impact of the items before they agree to add them to their backlog.

For the team, they are being asked to estimate complexity through Story Points. Inevitably, with multiple items, you will end up with ‘ties’. If you find that uncomfortable, and want more layering of the results, do 25 or 50 point increments on the Business Value rating.

Once each item is rated for complexity and Business Value, you can do a very quick calculation for each item in your backlog:

==============================================================================
Computed Business Value (CBV) = (Business Value) * (max complexity+1) – actual complexity
==============================================================================

Real World Example:

Should I refactor my error handling of this form or should I refactor my data caching model?

1. Refactor effor handling on a form: complexity (2), business value (100) or
2. Refactor data caching model: complexity (7), business value (400)

100 * (7+1)-2 = 600 CBV
400 * (7+1)-7 = 400 CBV

The next this the PO would do is take their backlog of items that have CBVs associated with each item and sort them according to CBV. A well prioritized backlog would be listed in descending order of CBV delivered.

More business value is returned to the organization at the end of the sprint by refactoring the error handling of the website form, in this case. It’s not that the second item delivers no value, rather that the mix of complexity and value doesn’t put it as the highest priority item in this simulated, 2 item backlog.

During team planning meetings, you can add a 5 second per item ‘broadcast’ of the CBV of the item, and begin to incorporate that into your lingo. You may find that people are challenging spike tasks and other demand work when the CBV isn’t higher than other items already committed to by your team for that sprint.

To some, it may sound like a lot of work, but I propose that having numerical data to back up how your team is doing is more critical than ever in the tumultuous waters of today’s economy. The calculation is easily automated in Excel. I’m sure that there are much more mathematically complex ways to calculate Business Value, but I’d offer this simplified approach up to the community for feedback.

I look forward to hearing your thoughts.