Einstein apparently said. “Everything should be as simple as possible, but not simpler”.
He would probably have said “Never use a tool you do not understand”.
From experience, most stories I’ve seen use the “As a… I want…” format with “So that…” added to improve their appeal to business investors. A bit like lip stick on a pig.
Consider these “So that” examples from a super duper tip top team I know…
- “So that I can start using the system”
- “So that I can cover my arse”
- “So that there is less risk to manual error”
The problem with “As a… I want” format is that business value is an afterthought. However, it is a dangerous after thought. Seeing it there leads the business to think that some thought has been put into value when the reality is it has not been.
A subtle but more insidious problem with the format is that the user is the starting point. This means that the target solution starts by assuming certain roles will perform certain functions. Often a project will result in responsibilities being re-distributed to different roles. This situation needs to be handled with care and delicacy. By stating who will perform which roles, you may be signalling to a user group that they are losing or gaining new responsibilities… both of which may be unpopular.
Although I do not use the formats, I prefer “In order to… As a… I need” which places business value up front as the primary concern. Check out Antony Marcano’s blog post for more detail.
The IT Risk Manager 
August 1st, 2011 at 5:40 pm
Hi Chris,
My thinking on this has evolved… I’ve tried to capture that in my post. To summarise the two key points I was trying to communicate…
1) The order in which we discuss things as we try to understand them does not have to relate directly to the order in which that information appears in a resulting artifact. In the same way that the title of a blog post appears first and the blog-content appears second yet (in my case) I usually think about and write the content first and come up with the title second.
Once we do understand the value and the feature we’re going to ‘inject’ into the implementation process I then find it more useful to lead with the information about the user and capability even though they came after me taking the time to understand and articulate the business benefit.
e.g. starting here is ok:
As [somebody I’m not sure who yet]
I want [some capability we’re not sure about yet]
So that we can increase our consumable sales
We can then ask ‘who buys our consumables?’ The answer allows us to fill in the “As a” section.
We can then ask ‘what do they need in order that we can boost our consumable sales?’ The answer fills in the ‘I want’ section.
Which takes me onto my next point…
2) Often, several capabilities deliver the overarching business value – yet often each story delivers value to the user… Because of that I think that the elements of a ‘user-story’ should be focused on the user. I think ‘business benefit’ should appear somewhere else… Such as in a theme. This also makes it easier to lead with the thinking…
Theme: In order to [some business benefit]
=> [story about a user doing something that supports the theme]
=> [another story about a user doing something that supports the theme]
…
So I’m suggesting that the content of the user story continue to use the old-school format but fall within a business-value theme:
Theme: In order to [some business benefit]
=> Story: [title of first story]
As [some role]
I want [some capability]
So that [some benefit to the user]
=> Story: [title of second story]
As [some role]
I want [some other capability]
So that [some other benefit to the user]
By the way – my new improved blog is at:
http://antonymarcano.com/blog
And I’ve copied the article you’ve linked to over too:
http://antonymarcano.com/blog/2011/03/fi_stories/
🙂