(Originally written by Thomas Botton and BenoĆ®t Pointet for the Scrum Alliance and posted atĀ www.scrumalliance.org/articles/380-key-dimensions-of-user-stories)
Dealing with a large amount of user stories (more than your fingers and toes can account for) is not easy, most often they sit one after the other in your product backlog, or they are shuffled on a story map. Dealing with user stories is basically projecting them in a space of dimensions. The three essential dimensions to our scrum process at LiipĀ are: the backlog order, the complexity (we call it effort), and the business value. Let's review briefly the first two and then focus on the third one.
Backlog absolute order
The product backlog order represents the urgency of a story. The absolute ordering forces the client to refine his understanding of the product backlog: there's only one single most important story to do next.
Story points
The complexity, is an integer value from the Fibonacci series, which represents a mix of technical complexity, work time, and even uncertainty bound to a story. Developers agree on it through the estimation poker game. Those two dimensions are commonly used in scrum teams around the world. The third one, business value, not so much.
Business value
Why isn't the business value that much used? Probably because scrum masters tend to forgive more to POs than to developers and because POs don't see the need to express this value. But business value matters ā to everyone in the team. Even more, business value represents something that's deeper than the reason of the user story, something laying deep into the business logic: the added value that the story brings to the business.
But that's so hard to express. Really? Really harder than estimating the complexity of a story? Think twice! Or rather, think the same: complexity estimation is relative and summative. Business value estimation should be the same: estimate the value of a story relatively to the others, and resume this value in a single number.
You got it! We do estimate business value the same way the developers are estimating the complexity. We ask the PO and stakeholders to play estimation poker ā and they love it! It's a unique opportunity for them to get together and come up with an agreement on story relative values.
Applying the same rules on estimating business value and complexity has an important side-effect: it brings understanding and respect in the project team. A PO will be more likely to understand why some stories need to be reestimated by the developers ā and vice versa. Using a numerical scale for the business value also allows to visualize it (cf. chart below), something MoSCoW can offer in a limited way ā if at all.
As an example, here's such a chart for the stories of sprint 1 (green), sprint 2 (blue), and the remaining of the product backlog (grey) of a small project we started recently. You clearly understand that stories laying at the top-left corner are the most interesting, which is why we took them in our first sprint.
The ROI (a.k.a Return On Investment)
Such a chart brings to your scrumish minds a sense of āReturn On Investmentā: the ratio between the business value and the complexity (aka. BV/SP). Since both are relative metrics, this is a relative return on investment that you'll never be able to translate into dollars, but which allows you to compare user stories. On the following chart, ROI is increasing in an angular way. It is now fairly easy to spot the undone stories (grey) with high ROI: 8, 20 and 30. Those are probably the ones that the PO will put at the top of his product backlog.
Those three dimensions are very flexible until sprint commitment. However, right before it, both the complexity and the business value must have been estimated for the top of the product backlog, which means that the product backlog has been re-ordered! The classical sprint commitment can then occur: the team pulls the stories from the top of the product backlog into the sprint backlog, negotiating order and amount with the PO. After commitment on a story, both its complexity and business value should not be altered, since it would tweak the metrics.