Rediscovering Business Benefits

June 5th, 2008  |  Published in Agile, Behaviour-Driven Development by Ian Robinson  |  4 Comments

Outcomes and the business value that we’re seeking to release in pursuing those outcomes all too often get passed over in favour of a morass of implementation trivia.

Desired business outcomes frame the delivery of application functionality, or more generally, service capabilities: they motivate software development. The outcome-driven bias of agile practices is reflected in the user story: in the Role-Feature-Benefit story sequence (see Dan North’s What‘s in a story for a description of these parts, and more recently Elizabeth Keogh’s RIP As a… I want… So that… for a compelling reformulation of the story format).

Sadly, many instances of stories try and get by without capturing outcomes and benefits. As one of the commentators on Elizabeth’s post notes: “the ‘so that’s’ are always the hardest thing to write in a story and are the first thing to be omitted.”

I see a lot of stories that neglect Role-Feature-Benefit in favour of the much easier Role-How-Feature. That is: as a <role> I want <something doing this way> so that <I can do this/this happens>:

As a user I want to export results so that I can share them with colleagues

Well, thanks for telling me how to do my job, and not telling me anything about what motivates yours.

Have we specified an outcome here? Not really. What we do have is a misplaced feature masquerading as an outcome, and a pre-emptive description of how to implement that feature. We’ve shuffled the desired outcome, the goal that motivates this feature, off the table. And by pre-emptively specifying an implementation, we’ve limited the opportunity for choosing between several implementation strategies – lo-fi, hi-fi – come implementation time.

When I spot stories like this, I try to “force” the issue of outcomes and benefits by performing a “shift left” on the story parts. Role stays the same, Feature shifts left, and squeezes How out. This leaves: as a <role> I want <to do this/this to happen> so that <??????>:

As a user I want share results with colleagues so that…

Now we’ve got a role, and a feature, and can start asking “why?” regarding the benefit:

As a user I want share results with colleagues so we can make an informed group decision about recent performance

Identifying the benefit allows us to turn the effort dial up and down. You need to do this, urgently? How about this workaround? Estimate: zip.

4 Comments  |  Atom   RSS 2.0   Email

Responses

  1. Stories and Capabilities :: iansrobinson.com says:

    October 28th, 2008 at 9:49 pm (#)

    […] lapses into specifying solutions rather than goals, and I’ll quite happily employ the shift left approach to highlight poorly constructed […]

  2. Kevin says:

    October 13th, 2010 at 6:49 pm (#)

    I have a simple question regarding what should be the correct Role in a story.

    The case is the following:

    The Product Owner has thought up a story which is about changing the telephone number where the customer can call after making a purchase. Right now, Marketing’s dept. phone number is listed in the e-mail sent out to the customer, but the Product Owner thought it would be wiser to put there a Sales representative phone number instead.

    So, my question is: is “Product Owner” the correct role for this story (because the PO was the one that thought that implementing this change would be benefitial), or is “Sales representative” (who is actually the one really interested on having the customer call him (and not Marketing), or “Marketing people”, because they want to be bothered anymore by customers with questions that have nothing to do with Marketing?

  3. Kevin says:

    October 13th, 2010 at 7:03 pm (#)

    There was a typo… re-posting

    I have a simple question regarding what should be the correct Role in a story, maybe you can clarify my confusion.

    The case is the following:

    The Product Owner has thought up a story which is about changing the telephone number where the customer can call after making a purchase. Right now, Marketing’s dept. phone number is listed in the e-mail sent out to the customer, but the Product Owner thought it would be wiser to put there a Sales representative phone number instead.

    So, my question is:

    Is “Product Owner” the correct role for this story (because the PO was the one that thought that implementing this change would be benefitial, or because he simply wrote it on behalf of the Sales representative or Marketing’s people because he thought it would help), or is “Sales representative” (who is actually the one really interested on having the customer call him -and not Marketing-), or “Marketing” people, because they don’t want to be bothered anymore by customers with questions that have nothing to do with Marketing?

    I would like to hear your thoughts.

    Thanks in advance.

  4. iansrobinson says:

    October 13th, 2010 at 9:05 pm (#)

    I’d say the Sales Rep, because they’re the direct beneficiary of the value delivered in implementing the story.

    Kind regards

    ian