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.
Once the development team has a well written story, they can work on the HOW. They are the experts in solving the technical problem presented in the best way possible. The product owner should rely on their technical excellence to solve the problem, not his own understanding. By not telling them HOW to implement a story, he allows them to be creative and innovative in solving the problem. A complete user story, which follows the invest criteria and answers the WHO, WHAT, and WHY will spark a conversation with the team and the product owner that will result in a better solution to the user story. If the user story is overly prescriptive it can reduce the ability of the team to create truly innovative solutions for your customers and the company.
What is important from your user stories is not how well they follow the formula, but rather that they begin a dialogue between the parties that are involved. We should always remember that the end goal is to provide more value to the customer and the stakeholders at the completion of every sprint and with every story. By writing effective user stories can be a lot of work, but by investing the time up front to have clear and complete stories, we can be effective and productive on the back end.
Reach out to us a learnmore@agiledad.com if you have any other questions or would like to learn more.