This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Sunday, June 22, 2008

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:
  • As a <customer role>
  • I want <functionality>
  • because <customer value explanation>.
Before explaining the new format let me dissect a little bit this old format. Why is it wrong? Clearly the most important thing we want to achieve with the User Story format is "focus on the customer", which for us means focus on the value that customer needs to achieve with the functionality we are developing. So the question is: why is the most important thing the last in the current used user story format?

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>
What do you think?

Labels: , ,

at 21:39
RSS link

Bookmark and Share

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 Blogger 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 Blogger Unknown, at January 25, 2009 9:31 PM  

Post a Comment

<< Home


 
(c) All rights reserved