Updated: Jan 20
Writing an effective user story can be a lot of work. Is it really worth the extra effort? Isn’t it faster to just have the product owner tell the development team what to do and how to do it? They should trust the product owner’s expertise and do exactly what he says, right? This command and control management style is not Agile, and you lose a lot of the benefits that come from collaboration between the 3 Agile roles.
A user story is how the product owner clearly communicates WHO, WHAT, and WHY to the development team. A well written user story provide a lot of information in a simple statement, that can be easily prioritized in the backlog and picked up by any team member to work on. With clear and complete user stories, the product owner can effectively communicate WHAT needs to be done and WHO will benefit from it. A user story should be concise, it is a placeholder for a future conversation and too much exposition can become overly restrictive to the development team.
The common formula for a user story is “As a <WHO>, I want <WHAT>, so that <WHY>.” For example, “As a <Online Shopper>, I want <to compare technical specifications between multiple products>, so that <I can quickly ensure that the product I decide to buy meets my technical requirements before I purchase>.” The WHO and WHY provide extra background to the team to understand the problem that is being faced, so that they can create a solution which fulfills the WHAT in the best way possible.
In his article titled INVEST in Good Stories, and SMART Tasks Bill Wake reminded us what makes a good user story. Keep this acronym in mind when writing your own stories, and eventually you will do it out of habit. These 6 points will help make your stories more meaningful and valuable to customers and stakeholders.