Example: As a the marketing manager, I would like logins to time out and log off after a preset number of seconds in case users leave their computers unattended.
Problem: A marketing manager may be a meaningless role if marketing uses the system exactly the same as advertising. Perhaps departments have administrators, super users, and casual users who use the system differently. In this case it may be better to have a role of administrator, super user, or casual user.
Improvement: As a customer who is logged in, I would like my login to time out and log off after a preset number of seconds so that I can leave my computer unattended and still have some measure of protection against unauthorized use.
At the other extreme is the most overused and overly vague persona: “As a user” and its variants. Knowing the specific role for a story helps us understand the context for the story, leading to better value and focus.
Example: As a business user, I would like a report of item profitability so that I can identify and highlight profitable items and consider what to do about underperforming items.
Problem: Who is this vague user? Is there a specific role that is interested in this report? Understanding that this story is for a specific role enables conversations about how to limit scope. In the previous example, “marketing manager” wasn’t appropriate; sometimes it is.
Improvement: As a marketing manager considering how to spend limited marketing dollars, I need a report of the most/least profitable items so that I can identify and highlight profitable items and consider what to do about underperforming items.
Another non-user is “the system.” Beginning the user story with the phrase “As the system” may enable teams to use a waterfall approach. The system doesn’t care if business value is delivered or not. With the waterfall approach, no business value is delivered until the end.
Example: As the system, I need to store customer account info and their order lists in the database.
Problem: This story doesn’t deliver any value to the end user. Manny’s users cannot directly use the database.
Improvement: These aren’t good stories by themselves. For most applications, avoid creating stories just for database work. Add the database capabilities as a task to other user stories. Good user stories are thin, vertical slices through the application and provide business value.
Beware when the story’s “so that” phrase is a restatement of the story’s “I want” phrase. This points to a lack of analysis depth. The real goal of the story is not at all clear, making it easy to be off target and develop software that doesn’t maximize business value. Such stories are often not analyzed well enough.
Example: As a customer ordering food, I want to locate previous food order lists so that I can see all the lists that I have.
Problem: This story doesn’t explain its value. In the case of Manny’s, why does the customer ordering food need to see lists? The answer could influence the usability.
Improvement: As a customer ordering food, I want to see my saved food order lists so that I can reuse the list for future orders, making ordering faster and more accurate.