Key Dimensions of User Stories

12 January 2012

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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

Aaron Steele, CSM, 1/14/2012 3:59:50 PM
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.
Benoit Pointet, CSM, 1/16/2012 1:15:39 AM
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.
Aaron Steele, CSM, 1/16/2012 7:45:40 AM
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.
Gagan Rana, CSM,CSPO, 2/2/2012 8:26:09 AM
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.
Pradeep De Silva, CSM, 2/14/2012 6:14:58 PM
Excellent article. The PO implicitly makes business value assessments and making this visible is a great idea!
Jon Innes, CSPO, 2/14/2012 8:29:01 PM
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.
Thomas Botton, CSM,CSPO, 3/19/2012 8:38:25 AM
Hi all,

That's interesting to see that BV and its benefits aren't used equally in the Scrum universe.

From the last two CSM and CSPO courses I took, the ROI topic (hence BV and SP) was discussed a lot and clearly: our Scrum projects should all be ROI driven.
At least from the PO point of view, that's what should matter the most!

And as Benoît said, the good consequence is that it brings transparency to developers of what is important to the business they work for.
I think it really helps the team to appropriate the project not only in technical terms, but also in business view terms. And that's always adding motivation when you know why you work on something and the reasons behind.

Another benefit it bring to have the BV number is its impact on the SP number thanks to a common understanding between client and the team.
Indeed, in a recent web project, we had to adapt the design (yes I talk about frontend like CSS and co) of a new product to be consequent with the other company's web products.
For us it was clear that we would spend quite some time and effort to make it similar so that end users feel like at home with this new product.
But after asking the client to put a BV on it, we started discussing with him as what he put was a very low value. Then we learnt that the company was planning a big redesign in the next months and that it wasn't so important to focus on the design at this moment.
But the initial story was just stating to make the design looking similar/the same as on the other ...
Surely, the user story was missing some infos, but clearly the BV helped to bring and clear out these points/infos.

I think that once you have used BV estimations in your Scrum projects, it sounds so obvious all what you get from it that you can't imagine starting a new project without it!
Scott Emery, CSM, 7/4/2012 3:59:59 PM
I have done complexity vs value charts in the past, but the idea that ROI increases in an angular way makes the graph really pop! The color banding makes it more intuitive and easier to read.

I also like the idea of having the PO use estimation poker (optionally x1000) to determine a set business value. In my mind, Scrum is all about making complex tasks simple, and getting a PO to prioritize has always been difficult to impossible. This just might work...
Mahfuzul Haque, CSP,CSM, 7/18/2012 12:44:43 AM
Great Article. Thanks!

You must Login or Signup to comment.