In software development a user story is a request to change or add behaviour to the product. Although the scrum guide does not mention user stories, they are widely considered as being part of the agile software development. Writing good user stories is a key aspect of delivering high value to the customer. Investing time in writing a good user story leads to spending less time in the development phase and is therefore simply a matter of cost. In this article I will give you five essential hints to write better user stories and therefore to ease the delivery of high value to your customer.
Who writes user stories?
Although it is the responsibility of the product owner that a backlog of user stories exists the product owner is not the sole writer of stories, a user story can be written by anyone.
Therefore, the given hints should be followed by everybody who feels the need to contribute to the products increment.
1. Write the story from user perspective
The software that you are going to deliver is for some user. Hence what is closer than to write the desired change from that user’s perspective. It is therefore needed that any story writer truly understands how a user interacts with the current increment as well as the user might interact with the future increment as well. Consequently, it is essential for a story writer and especially for a product owner is to get in contact with their users and their customers.
As a user might not be available at any time a helpful tool might be so called personas. A persona is a virtual user of your product which somehow shows a stereotype[1]. Use these stereotypes to identify different types of users and their different needs. Personas are a good starting point to understand the audience of your product.
[1] https://medium.com/beakerandflint/personas-74c4e1c12ee2
2. Write stories collectively
In the software development work, pair programming is known to deliver high quality implementations as there are four eyes looking at the changes done. The interaction and the exchange of ideas as well as critical thinking about the work of others on the go really puts some focus of the outcome (rather then the output). This kind of collaboration can be easily adopted to story writing as well. Having two writers instead a sole person, will boost the creativity of the story creation process and will lead to a well thought story, looking at aspects of the story a single person could not even imagine.
3. Don’t stick to the happy path only
In the creation of a story the writer might think about what a user wants to achieve by using the desired function. The writer describes the happy path in which the user is going to do all necessary steps correctly and in the correct order. Additionally, all preconditions are set correctly. Sadly, this will never reflect the real world. In the real world what can go wrong will go wrong. Thus, the unhappy path of working with the product needs to be part of the user story as well. Describe what needs to happen if the user did not meet the preconditions or even what might happen if the product itself did not react as you expect.
- What should the error message contain?
- How should the product behave in case of an unexpected error?
- Which options did the user have in case he made a mistake?
4. The user story is the main input for QA
An important part of product development is quality assurance[1]. Within the quality assurance the development team checks whether the implementation matches the needs of the user. These needs are written down as part of the user story. Surely the product knowledge can be used as an entry point for quality assurance, but it needs to have some “truth” to compare to. The user story is an essential source for this truth.
Therefore, the QA process does not start at the end of the life cycle of a product change but already in the process of creating the user story. This guarantees to not only deliver quick and frequent changes to the user, but real value that can make the users life better.
[1] https://medium.com/p/9fabd1f6c66e
5. Technical details should be added by the developer
As already mentioned, writing the user story is not the sole responsibility of the story writer nor the product owner. It is truly essential that the story is complete and understandable by anybody when you start implementing it. That means that the development team needs to contribute to the story. In many cases the development team knows their product very well and get help to deliver the best value to its customers.
But as already said, the user story is written from a user centric view and needs to be understood by anybody in the chain of product delivery. This concludes that too much technical details should not be part of the story itself. Also, it is not in the responsibility of the story writer nor the product owner to deliver the technical details needed to implement the story.
Technical details are surely needed to implement a story correctly, but they are not part of the story itself. They should be added as part of a task. A task beneath the story is the right place to note the details needed for a good implementation. A story describes what is needed. The task beneath describes how it can be done.