Video: Effective Product Owners use the “Business Value” Field

Watch this SSW TV special video on “Estimating Business Value to order your backlog” and see a real-life video of a brand new Scrum team learn how to use the “Business Value” field.

Yesterday I told you about the lightening fast, dead sexy movie site, ‘Event Cinemas’ that went live. Today I have a real gem from SSW TV. This video shows a little of how that sausage was made and hopefully you will get a great takeaway, that you can use in your own Scrum team.

One thing that is practically universal in our industry is that we let Product Owners get away with far too much. Product Owners are typically extremely busy people and I believe that most dysfunction that happens in Scrum teams comes down to the Product Owner. Letting a Product Owner skip estimating the “Business Value” does *not* make developers work better together.

So how do we estimate Business Value?

Well, we know that developers love the Fibonacci sequence (1,2,3,5,8,13,21), but the last thing you want to do, is teach Product Owners about how hip Fibonacci is, because it is slightly complicated and unnatural to those non-mathematically minded.

Therefore these days I much prefer the “Doubling” method (1,2,4,8,16,32) as it is far simpler for Product Owners to understand. Even better, I prefer that the developers switch to estimating their “effort” using the same scale, then things are much easier all around.

So come on and lets get this happening in all Scrum teams!

I propose the following:

1) Let’s make ‘Business Value’ *not* optional, and explain to Product Owners that if it’s good enough for a developer to estimate “Effort”, then it’s good enough for the Product Owner to estimate “Business Value”.

2) Let’s talk the Microsoft TFS Team into providing us with a ROI field and a chart for “Business Value” (as they do for Effort). Tell them, they listen. Vote on my suggestion.

3) Once you have had a good experience using it, then tell Ken Schwaber and Jeff Sutherland that “Business Value” is really important and we want it in our beloved The Scrum Guide. And it wouldn’t hurt if it was also in the Terminology section of their book, Software in 30 Days.

Of course, many Scrum teams don’t bother with “Business Value”, so why should you?

There are plenty of benefits, starting with:

  • Helping you order your backlog
  • Finding the low-hanging fruit (easy tasks that give high value) and
  • Forcing communication

If you have comments on why you like, or dislike, “Business Value”, let me know.