The standard user story format is, "As a role, I want goal/desire so that benefit." For some user stories, however, this straightforward template goes haywire when it comes to figuring out who should be listed in the role field.
For example, in a recent thread on the Scrum Development mailing list, Kevin Krac asked about the following real-life user story:
The Product Owner has thought up a story which is about changing the telephone number where the customer can call after making a purchase. Right now, Marketing's dept. phone number is listed in the e-mail sent out to the customer, but the Product Owner thought it would be wiser to put there a Sales representative phone number instead.
Who should go in the role field when formulating this particular user story? The Product Owner? A member of the marketing department? A sales representative? Someone else?
Why include a role field in user stories at all? Don MacIntyre gives one reason: "I've found that clearly identifying the role as the beneficiary helps Product Owners come up with a clear value proposition—which in turn helps them to prioritize the story." In this story, though, it isn't clear yet who benefits when the development team completes it.
Ron Jeffries sees little value in adhering to the standard story form:
What is on the card is hardly relevant at all: I would favor something like "Replace Marketing phone number with client sales rep number."[...]
Thinking is important. Choosing the most valuable stories is important. Explaining to the team what is finally decided is important. Having concrete tests to be sure it works is important.
What is written on the card is less important than any of those.
Mike Cohn, however, sees some advantages in the standard user story format. The advantages he sees include:
- Placing user stories in the first person ("As a ... I want ...") helps developers and others identify with the beneficiaries of the work they are doing.
- Structuring all the stories the same way helps the product owner prioritize among them by removing the need to mentally parse the text of each user story individually.
To make the standard format work for non-standard stories, Mike Cohn has a couple of tips:
A good user story can be about any stakeholder of the system. And the story can just as easily be something other than "want" as in "As a shopper, I am shown complementary products when I start to check out." Or, "As a user, I am forced to change my password every 90 days." So not all stories need "want" in them.
Filling in blanks in a user story template, however excellent that template might be, will not do the hard work that needs to be done. The keys to user story success are, as Ron Jeffries puts it, "Card, Conversation, Confirmation". That is, make a card with just enough text to identify the requirement (a "user story"), have just enough communication between the customer and the programmers to be able to code that requirement successfully, and confirm the result of the completed work by means of an acceptance test.
