A user story is a way of describing what the user needs. It’s a short and simple description told from the perspective of that person.
A user story tells you:
- who the user is
- what the user need is
- why the user needs it
Why create user stories?
User stories help you understand the needs of all your users, rather than a single individual or the business. They help the team know exactly what they need to build and why it’s needed.
In traditional development, the business would assume what the user needs, or users are asked what they want. That leads to solutions that don’t always address the real problem (what people want, isn’t always what they need!).
So it’s key to understand the user by researching their needs and their problems and translating that evidence into user stories. The development team then comes up with the best solution based on the stated problems.
User stories also foster collaboration and discussion amongst the wider team and that collective wisdom leads to the creation of better products.
How to write user stories
Writing user stories isn’t an exact science, it’s more an art. Two people will write user stories very differently, without either being ‘wrong’. So the art of writing effective user stories develops with practice.
Write user stories from the point of view of the user, rather than a developer or product owner. Use everyday language and capture what the user is trying to achieve.
User stories usually have this structure:
|As a [user role],||As a teacher,|
|I want [goal],||I want to see my class timetable,|
|So that [benefit].||So that I know what classes I have coming up.|
Capturing them clearly and succinctly helps:
- make sure you solve the right problems
- foster collaboration
- the product manager know when the stories are complete and meet the users’ needs
Verify your stories
To convey the right level of information, it’s important to read the user story from the perspective of someone else in the organisation. Ask yourself whether it would make sense to them and if it conveys the right level of information?
You can apply the well-established principles of INVEST to help you write a good user story. So, make sure user stories are:
- Independent of all other user stories,
- Negotiable and changeable until they’re in development,
- Valuable to the end user,
- Estimate-able for the team to be able to size the work
- Small enough to be able to plan and manage the work; and finally,
- Testable, to make sure the story is defined and can be tested.
You want to avoid describing the solution in user stories. That’s the job of the development team who are the solution experts.
Managing user stories
You can write user stories electronically or physically. Post-it notes or online whiteboards are handy as these foster engagement and bring teams together.
Make sure user stories are broken down to the right level of detail. Do this with the user, work on it yourself, and with the wider development team. If it’s not a priority, you should leave any large user stories (your development team can tell you if the user stories are too big and need splitting up) in the backlog. As the user story moves up the priority list, break it down into more granular user stories.
Ultimately, to write user stories that are easily understood by a development team, there’s a balance that needs to be struck between providing too much and too little detail. And the best way to find this balance is by getting the team to critique the stories and make sure they’re clear so anyone/everyone can understand them.
Writing the acceptance criteria
User stories are a great way of quickly conveying a lot of information, but when do you know you’ve actually completed one? This is where writing acceptance criteria for each user story will help.
The acceptance criteria defines the boundaries of a user story and confirms when it’s complete.
It usually looks like this:
|Given [a scenario],||Given I am a Teacher AND I am on the ‘Forgot password’ screen,|
|When [something is done],||When I have entered my email address AND I have pressed ‘Submit’,|
|Then [this happens].||Then I shall receive a message to my email inbox containing a link to change my password.|
Acceptance criteria help:
- the team think through how a feature will work from the user’s perspective,
- remove ambiguity from requirements
- form the test that will confirm a feature or functionality is working and complete.
Again like with the user stories, check their validity — whether they’re easy to understand and whether it’s clear what problems need solving.
User stories are a great way of keeping the needs of users at the centre of your team’s work. It encourages discussion and collaboration that ultimately leads to the development of better products.
3 ways to master agile delivery in governmentPublished on: 18 October, 2023
Why you should involve solutions architects early in agile projectsPublished on: 5 July, 2023
How to effectively manage legacy technology in governmentPublished on: 12 April, 2023
User research in government digital services: 7 steps to get it rightPublished on: 2 March, 2023