Key Dimensions of User Stories

January 12, 2012

6

By: Benoît Pointet & Thomas Botton

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.

Share on Facebook    

Article Comments

  1. Aaron Steele said on 14 Jan 12 15:59:
    Great article. I agree with you 100%. This is one of the problems I see on a regular basis where it is hard for a development team to understand "why" they are doing something and take full ownership. In some cases, it seems like the business is splattering paint on a canvas to see sticks. Where as with value and return transparent, it would be easier for both the developers, as well as the PO, to understand what real value a sprint or release is producing. You could take it a step further and apply the teams run rate to even further expand on the stories that don't make sense, i.e. story x produces y value, but costs z. If z is greater than y, the story should be looked at as potentially providing negative value.
  2. Benoit Pointet said on 16 Jan 12 01:15:
    I agree with you: the key is to make things clear to both the development team and the product owner. "" ... story x produces y value, but costs z. If z is greater than y, the story should be looked at as potentially providing negative value ..." I think you have to be careful when comparing business value with story points. Although both might be measured using the Fibonacci scale, you cannot relate them directly. You cannot ever say this story produces more than it costs, because its business value is estimated higher than its complexity. Again, both are relative metrics, which mean that they are only useful at comparing stories. We started using a shifted Fibonacci scale for business value (Fibonacci * 100) so that the business value scale empahsizes the business side of it (lots of zeros!). For non mathematicians, it's also good to have ROIs between 1 and 10'000 rather than between (0.01 and 1). As a side effect, using such a business value scale, makes it clear that you cannot compare the business value and the story points of a single story.
  3. Aaron Steele said on 16 Jan 12 07:45:
    Sorry, I put my own assumptions into your article :) I agree that based on relative "sizing" of business value and estimating in points, it would be difficult, if anything inaccurate to do a run-rate analysis. I was thinking in terms of dollar-value and time-estimates at the decomposition level. Either way I still think the idea of estimating business value is solid and probably more easily attainable than specifics. The end result should be about transparency and understanding as you mentioned. Thanks again for a great read.
  4. Gagan Rana said on 02 Feb 12 08:26:
    Good article. In my experience business value is required to be discussed with PO and drafting such graphs could be ideal. My PO/Scrum Team just priotized which features will be delivered first and all the doable stories within that feature. I guess business value of stories comes next to business value what feature provides.
  5. Pradeep De Silva said on 14 Feb 12 18:14:
    Excellent article. The PO implicitly makes business value assessments and making this visible is a great idea!
  6. Jon Innes said on 14 Feb 12 20:29:
    Hi guys, I enjoyed the article. I've been thinking about the same things. I'm a CSPO that has a UX background. One of the things I think is missing is often the consideration of value of a story. Too often teams look at what's easy to do, rather than what adds value to customers or to discovering what might add value. It seems all too often that during grooming we neglect that some stories add more value than others, and often all the value judgements are very subjective. I recently blogged my thoughts on the topic at http://www.boxesandarrows.com/view/integrating-ux-into and would love to hear your feedback.

Please login to comment on this article.

Authors

Thomasbotton_100x100

Thomas Botton CSM

bio

Thomas Botton, former Scrum Master and now Product Owner at Liip (http://www.liip.ch). Very interested in all practices which make you Agile (i.e. Scrum, XP, TDD). I'm also a web developer, last te... Link »

F2

Benoit Pointet CSM

Tags