Writing User Stories the 5 Ws Way
A User Story is written by any User. The User Story should have a short but descriptive title and a longer narrative. The narrative should include the 5 Ws: Who, What, When, Where and Why.
- WHO: Usually, the type of user (ie Admin, Student, Teacher)
- WHAT: What the user in the WHO is going to do (clicks on the "new blog comment" button)
- WHEN: "When" may describe a time or date or relative time (ie After logging in or after reading a blog)
- WHERE: Where on the page or in the application.
- WHY: What was the trigger for the user (user wants to suggest a change to the blog post)
Example 1: A student (who) clicks the new blog comment button (what) after reading a blog post (when) located at the bottom of the blog post (where) in order to make a comment about the blog post (why).
Discussion 1: Example 1 is pretty straight forward the who, what, when, where and why are well defined. Let's look a more complex example.
Example 2: An instructor (who) has determined which students to put into which discussion groups(why,when). Viewing the student listing for a class (where) clicks the checkboxs next to several student names, selects a discussion group from the drop down and clicks the add to discussion group (what).
Discussion 2: Example 2 is a bit more complicated. The "what" is a bit more protracted and the "why" and "when" are combined. For more complex stories it may be easier to list the 5 Ws first:
Who: An Instructor
What: Selects multiple students (at once) and adds them to a discussion group
When: After determining what students go in which groups.
Where: From the student listing screen.
Why: To get students into discussion groups.
In this format the when and the why come out a bit differently. Using the 5Ws method can greatly reduce the amount of time it takes for users to produce good stories. When all stories are written this way they become easier to estimate and the why element give valuable insight into what a user expects from the software.
Note: (Added 2 Sep 2009) In fairness to the SCRUM world this could also be expressed in SCRUM Style: As an instructor I want to add multiple students to the discussion groups from the student listing.
Feel free to suggest additional examples or make comments!
Comments
In this example, we assume a mouse and some certain ui gadgets. Shouldn't we remove these references to the actual implementation and leave that up to the interaction designer and developer?
A user story is just the beginning of a discussion. I wouldn't over analyze it. Users should feel free to express common UI elements. In most cases they have a good idea of how they want to do their work. If you have user experience people or just smart developers you can help suggest alternatives. The point is to get insight into how a user "uses" your software.
What you DO want to avoid are stories that specifically suggest infrastructure or service elements. Things that throw red flags for me are terms like "Web Service", "Array", "SQL Query", "Stored on the Hard Drive".