The tendency of people to dictate solutions, rather than the problem that needs solving, has lead some to emphasise that we should put the benefit of the story first. For example, let’s say a fictional printer manufacturer consistently entices 3% of everyone they e-mail, reminding them to check their ink-levels, to purchase print consumables. In this situation, some might illustrate taking a story like this…
As the PrintCo marketing manager
I want customers to register their e-mail addresses
So that we increase the sales of our print consumablesAnd changing it to this:
In order to increase the number of sales of our print consumables
As a marketing manager
I want customers to register their e-mail addressesThe intent behind this shuffling around is to get people to think about the problem in order of business value first, then the stakeholder then what the stakeholder thinks will deliver the value.
But, the story is talking about a stakeholder… In my experience, this doesn’t get the best value from the user story approach.
Stakeholder ‘stories’ or User Stories?
I’ve found that user stories are most useful when communicating to the team if they encourage a conversation around who the user is, what capability the user needs and why it’s important to the user (could that be why they are called “user stories”?). This helps us to understand what user experience they need and what capability will make that possible.
This is an interesting take on getting to the big picture from user stories, and a useful way of thinking with Customer Development. The post goes into a deeper discussion, so check it out on Antony's blog. He also has a class coming up at Skills Matter in April: http://skillsmatter.com/course/agile-scrum/antony-marcano-feature-injection-c...
