For a better format for User Stories
Karl follows up on a post by Liz Keogh about the fact that User Stories need to have a different format. The original format was:
When teaching User Stories I've started to teach a "thinking model" (credit to Pekka Usva for pushing me to do this). It goes like this: whenever you start writing a user story always, always start by writing the goal (because...) part first. Never, ever write the functionality (I want...) first.
That's why Karl's post clicked: it makes perfect sense to change the format of the User Story. Therefore I hereby join my (blog) voice to his and Liz's and suggest to the community: let's start writing User Stories with the following format:
at
21:39
- As a <customer role>
- I want <functionality>
- because <customer value explanation>.
When teaching User Stories I've started to teach a "thinking model" (credit to Pekka Usva for pushing me to do this). It goes like this: whenever you start writing a user story always, always start by writing the goal (because...) part first. Never, ever write the functionality (I want...) first.
That's why Karl's post clicked: it makes perfect sense to change the format of the User Story. Therefore I hereby join my (blog) voice to his and Liz's and suggest to the community: let's start writing User Stories with the following format:
- In order to <value to achieve>
- as a <customer role>
- I want <some functionality>
Labels: agile, requirements, user stories
RSS link
2 Comments:
I agree that you should focus on the VALUE [benefit] first, before the [feature], when WRITING a user story.
I question the value of putting the story in this format when COMMUNICATING it, however. Once written, the purpose of a user story is to communicate the idea.
The 'old' format encourages the READER to think about things AS a person in a particular role, giving it a first-person perspective. Then, it presents a potential behavior of the system that the user in that [role] might experience. While reading the feature, they likely already begin to see the [benefit]. Finally, it presents what the reader probably already sees, which is WHY the [role] wants the [feature]. Having the user come to their own conclusion before you state yours, especially when they match, is a great way of garnering support.
It is my opinion that you make the user story less effective if you alter the layout in the proposed manner.
By
John Arrowwood, at November 20, 2008 1:14 AM
@John Your argument is sound and I don't see any logical flaw in it. My problem is with the reality of the "old" User Story template.
No matter how much we stress the need to have the "value" properly described I don't see anyone (literally) using it before I have to do the 5 why analysis on the "feature" so that the person understands the deep reason why that "feature" is valuable to the user.
I also see that people don't spend anytime writing the "value" part of the clause, they tend to use banalities and obvious things. That delivers zero value when communicating the user story.
Anyway, I wrote another post about this to explain further the reasons why we should use the template I suggest in this post. Check it out: http://softwaredevelopmenttoday.blogspot.com
By
Unknown, at January 25, 2009 9:31 PM
Post a Comment
<< Home