BT

New User Story Format Emphasizes Business Value

by Chris Sims on Jun 19, 2008 |
Since the early days of agile, user stories have been a common way of capturing requirements. These short bits of documentation, often only a sentence or so written on an index card, capture the essence of the desired functionality. A conventional format for these stories has been:

As a <type of user> I want <some functionality> so that <some benefit>.

Elizabeth Keogh suggests that business value is more important than user role and presents a revised template for writing user stories, which she credits to Chris Matts. The traditional format emphasizes the importance of the user, mentioning them first. The newly proposed variation switches the emphasis to the business value:

In order to <achieve some value>, as a <type of user>, I want <some functionality>.

The change may be subtle, but it is likely to resonate in a value-focused environment.  Elizabeth goes on to describe how the focus on value carries over to planning a software release:
The word 'release' is more meaningful. There's some untapped money out there - some market share, some cost saving, some battle against a competitor. All the features we produce go towards releasing that value for our customers to use - and it's the value we're releasing, not the features.

Would refocusing users stories on business value make a difference in your environment? Leave a comment and share with the community.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I like it. by Karl Scotland

I blogged about it >here.


I think the new format gives a clearer way of managing the relationship between the small incremental functionality pieces, and the larger value pieces.

Some views on the format by Ajay Danait

These are some views from my manager on this format :



In order to [achieve some value]
As a [role]
I want [some feature].




i feel


#1 - it is heavy, and not so natural (more written language than oral one)

#2 - takes only the 'value' perspective, and hides the 'risk mitigation' side




-> in the product backlog, we found great to consider priorities on 2 axis : value creation vs risk mitigation




=> good thing when you talk to a end-users in our business, especially it will emphasize the 'OR' sensitivity




As a <type of user> I want <some functionality> so that <some benefit>.
should be turned into :-



#A - As a [type of user] I want [some functionality] to avoid [some operational risk, process weakness, ...]



#B - As a [type of user] I need [some functionality] to get/maximize/fasten/point.... [some benefit]. </some></some></type>

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT