User stories are brief descriptions of the functionality expected from a system or product by the end-user or customer. Hence, they are written from the user's perspective.
The format of the user story is as follows:
As a <type of user>, I want <some feature> so that <some reason>
Let's understand each element of the user story format:
As a <type of user> — this is the WHO. Who are we building this for? Who is the user?
I want <some feature> — this is the WHAT. What are we building? What is the intention?
So that <some reason> — this is the WHY. Why are we building it? What is the value for the customer?
Even with a template for user stories, many agile teams struggle to write user stories that fail to achieve the intended benefits, making them lose confidence in the agile approach.
Don't let that happen to your teams.
Here are six best practices to help you write better user stories.
1. Write user stories using "Personas"
When user stories are written using personas, they generally capture the customer's need better. Personas are fictional characters based on first-hand knowledge of the target group. They usually consist of a name and a picture; relevant characteristics, behaviours, and attitudes; and a goal. The goal is the benefit the persona wants to achieve or the problem the character wants to see solved by using the product.
Personas help you capture the reasons why your target group would want that story and the value the story would bring to them. Using this technique, you can build more valuable features for your product's audience.
2. Link smaller stories to epics.
Child user stories usually have a parent story. In agile parlance, these parent stories are called Epics. Epics are defined first after which they are broken into several smaller user stories over time. Epics allows you to sketch the product functionality without committing to the details. They also capture the rough scope of the end product and gives everyone involved in the project a sense of what the end product might look like.
3. Let stories have minimal dependence on each other.
Good user stories have minimal dependency on each other. This helps with scheduling and development. The advantage of keeping stories independent is that this enables flexibility in the order in which the stories are built. One strategy to reduce dependency is to roll dependent stories into a single independent story. Obviously, not all story dependence can be eliminated, but the greater the independence, the easier it becomes to move stories around.
4. Stories are estimatable
Well written stories are easier to estimate. Estimating the story size (effort) helps with story prioritization. Generally, stories which are estimatable have been better researched, and the understanding of the story is deeper amongst the people trying to estimate it.
5. Stories are small
Good stories are granular, small enough to fit into a sprint. When stories fit into a sprint, that means that they'll be finished and shipped in that sprint. That's excellent news for customers. Generally, a story should comprise a max of 3-4 days of work and it includes all the work to get it to a done state.
6. Support stories with acceptance criteria
Good user stories are supported by acceptance criteria. Acceptance criteria make stories testable, quantifiable, and measurable and don't leave any room for doubt that the story might be incomplete. Before stories get shipped out to customers, they must be tested against the acceptance criteria to confirm if they are 'done' or not.
So, there you go. Get started with these user story best practices and keep improving your ability to write user stories gradually.
To learn more about such topics in scrum, please feel free to attend our 2-hour free scrum webinar. Click here for registration.
Test your scrum knowledge with the Foundational certification in Agile Scrum (FCAS™) exam. To register and take the exam, click here.
Comments