(this article was originally posted on my blog)
Most of my posts are just personal notes I take to reflect on my daily work or to prepare for a meeting.
Sometimes I think they could be food for thought for someone else and as it happened today, here I am writing these lines.
I asked myself 3 simple questions:
- Why do we write User Stories?
- How should we write User Stories?
- What are acceptance criteria used for?
Just to give you some context, I’m talking about user stories as units of work in an agile framework.
I know there is an immense literature on this subject and I don’t want to reinvent the wheel but I took the time to think and respond with concise and clear answers.
Stories focus on users and their needs and are aimed at solving real problems and to add real value to the project.
Stories empower critical and creative discussions about the product in the development team and create conversations between the development team and the external stakeholders.
With each passing story the development team enjoys a small challenges and a small win, driving momentum.
In order to describe a functionality from a user’s perspective, we use a simple structured template:
“As a User Persona, I want to …, so that …”
Who is the user? Who are we building this for?
What is the User trying to achieve?
What does the User want/need to do?
I personally find very useful what Max Rehkopf [wrote here](User Stories | Examples and Template | Atlassian: <>
What is the problem that needs a solution?
It’s very important to set some boundaries from technical and design perspective.
When acceptance criteria are met, the story can be considered done.
The development team and the customer must have the same expectations about the outcome of the story.
Well defined acceptance criteria could generate clear subtasks.
I would be delighted to know your opinion on user stories, how you would have answered the 3 questions, what tips and tricks you use in your work.