Does "the perfect user story" exist? How should a user story be structured so that it meets your team's expectations? We'll tell you everything you need to know.
As a product owner, you are busy every day writing one user story after another. Expectations are high: You want to deliver high quality user stories to your team and stakeholders in estimation and planning meetings. A well-prepared user story is also a good use of valuable time by avoiding discussions about the structure, size and content of the story in meetings.
But as you know, time is money.
So, what does it take to make your user story perfect?
- User Acceptance Criteria (UAC)
- Other helpful information
Let's start with the title
The title must be the right length. If it is too long and complex, it will be only half read and not understood. This means that we already lose the team's motivation as the title already doesn't appeal to them.
Try to keep your title short, but get to the heart of what the story is about. If the title is short and to the point (but still meaningful), you have managed to give your team a first idea of the story content already when they read the title.
Here are some examples to give you a better understanding:
- “Payment method purchase on account available in the check-out”
- “Activation of the Wish list”
- “New product category shoes added”
Now we write the story.
Here you should definitely follow the structure below so that the three core questions "Who", "What" and "Why" are answered:
I'll give you an example: As a Modelando customer, I want the payment method "purchase on account" to be available in the check-out so that I don't have to pay my invoice until I receive the goods.
With this story, we know who (the Modelando customer) wants what (payment method purchase on account in the check-out) and why (so that the goods can only be paid for after reception).
All right, so far? Great, then let's continue with the UACs.
UAC stands for User Acceptance Criteria and means: What must be done in order for the user to consider the given requirement as completed. The UACs also give the responsible developers a little guidance on what the behaviour must look like in the end for the story to be considered fulfilled.
In our example, the User Acceptance Criteria could be as follows:
- UAC 1: The payment method purchase on account is activated.
- UAC 2: The customer can select the payment method purchase on account in the check-out step payment method and thus complete the check-out
In the case of possible design specifications, the following could also be included:
- UAC 3: The payment method purchase on account is displayed in the Modelando-CI and appears in second place among the payment methods.
Does it tickle your fingers, and you want to sit down and work on the story?
In other words, describe what to do in simple terms. Technical specifications are not included, because that is the responsibility of the developers themselves. When we read this story, everyone - the developers, our stakeholders, the customer, etc. - has to feel addressed.
The clearer the requirements are written down, the easier it is to understand. The clearer the requirements are written down, the fewer questions you will get.
At the end, you add further information
Do you have designs? Attach them so one can get an idea of what is expected.
Are there dependencies on other stories? If so, note them immediately so that possible blockades could be cleared in advance or cleared out-of-the-way if necessary.
Summarized again: Key tips to help you write a perfect user story:
- Take enough time for it - it is definitely time well invested.
- Write a short, but meaningful title.
- Formulate the story according to the "who - what - why - procedure"
- Describe UACs in simple words
- Complete the story with all the necessary information that is relevant for implementation
Andrea and the whole agile team are available to talk about agile topics and help you implement a real and effective change culture. Leave us a message.
Then we recommend our article series on Decision-Making in Agile Software Development. We explore why it’s especially important in agile teams to address how decisions are made.