Most development teams I know try to figure out how to write great user stories. Especially that the well-known format for user stories probably won’t give them the results and success they’re looking for. So what makes a great user story?
It’s not as simple as it seems. Let me take you on a ride and show you:
How to write a user story from user’s perspective
To make things simple, I’ll use a job searching portal as an example. After all, we have all looked for a job at least once, right?
What is a user story and what isn’t?
A user story (a story for short) is a small chunk of work that’s written in the form of an anecdote from user’s perspective. More precisely, it describes the outcome or delivered value from the user’s perspective. For example “As a Job Seeker, I want to search for jobs by location and position, so that I can find a new job quickly”.
The story definitely isn’t a technical task (like making an endpoint or setting up a database) or a research task (often called Spike). A completed story has to be immediately useful for a user. You can use the popular template:
And you can do it however you want as long as the story represents value for users. Try to make it simpler e.g. “A (who?) can (what?)”. Great stories aren’t made by great titles but by the correct process of Product Discovery.
Stories play a key part in software development and have multiple purposes. They are the user’s needs, descriptions of the product’s features, a token for conversation and are an important part of the planning process.
How to identify your regular users
Before you write your first story, you need to fully understand who is your user. Once you know it, you’ll know whose perspective to take to create a story. If you don’t know who might be the customer or user for your product, you need to find it out.
When you’re ready, set a 5-minute timebox and generate a few ideas for names of average users or roles in your app on sticky post-it cards. Generate as many ideas as you can. Pin your post-its to the nearest wall and try to group roles for 2 minutes. Then repeat the process again. You can remove, consolidate or split the roles any time during this activity, just write it down on a new post-it.
I have generated, grouped, consolidated and removed a few of my cards. Here are the roles I have come up with for job searching portal:
The set is good enough to start writing the stories for my job searching portal.
Start with big user stories
Start with the goal that each identified role has for interacting with your software and write it down. Then focus to write for one user at a time with action verbs. Start from the most important role for your business.
Let’s say, I have chosen to start with Job Seeker. I pinned to the wall this post-it a little bit further from the other roles. What’s Job Seeker’s top priority goal? To find a job. And for example the first 4 big goal-oriented stories I’ve come up with are:
Compare salaries based on position and location.
I’ve pinned these 4 post-its below the user role as it’s shown on the picture below.
Make the user stories flow
Now, try to order your user stories in chronological order from left to right. You should be able to tell someone a story about a Job Seeker by going through each card (starting from left to right side).
Try to spot holes in your flow. During this activity, you could realize that a few stories are missing. Maybe Job Seeker needs to sign-in and sign-up before will be able to search for jobs. Maybe you’ll need a simple settings section or something else. Add post-its to the wall and reorganize the user’s flow. Maybe before Job Seeker can apply for any job, someone needs to add job offers to the system?
Move smoothly to the next user role you feel you need to go through to fill in the holes in the flow. Pin the card with the next role to the wall, just like you did for Job Seeker. Repeat the process from big goal-oriented stories for the next role. Once again, try to tell the story by reading the map you created.
Congratulations! You’ve created your first backbone for user story map.
In fact, these are the high-level stories and are the perfect starting point for the Scoping Session or the Story Workshop. Do it with your Development Team and generate more stories, split the big ones into smaller and discuss the details. After Scoping Session everything is ready to start the development of the MVP.
How not to write too many user stories in advance
If you’re wondering why you shouldn’t write all the user stories by yourself, the answer is simple. It’s not effective.
Bring it to the team instead. You need to gather the stories with your Development Team, with potential and existing customers and users. Focus on achieving a shared understanding during these meetings.
Stories gain details over time. It’s inefficient to write them all at once and with perfect details. That’s why user stories for the next few iterations should be sized and detailed only enough to plan them into Sprints. User stories that are further away in our “horizon of features” could be much larger and less precise. However, you should still put them in Product Backlog.
Keep the UI out of the user story
And keep it out as long as possible. Good stories are focused on the outcome, not the output. UI, UX, code implementation, and other technicalities – it’s the output. An outcome is what happens when output is Done. An outcome is something you can observe just after Sprint’s result is handed over to users. You could see then if it’s useful and meaningful for them, in other words, if it’s valuable. Try to maximize the outcome with the least amount of output.
During the Scoping Session, describe the stories or ideas for stories as a problem you want to solve or the outcome you want to achieve. Don’t ask the Development Team for the output you have imagined. A lot is unknown at the beginning and a skilled Development Team can advise you how to achieve the same outcome much easier.
Write closed user stories
Developers often write tests before they write the code. It helps to check quickly whether everything works as intended and keeps the quality high.
It’s the same with user stories and Acceptance Criteria (for short AC), which are the details of each story that helps us to answer important questions:
How exactly this should work?
Besides that, try to write closed stories. A closed story gives users a feeling of accomplishment when finished.
How to write closed user stories? Let’s take a look at a few examples:
“A Recruiter can review resumes sent for placed job offers.”
“A Recruiter can change the expiration date of a job offer.”
“A Recruiter can delete the application that’s not fit for a job offer.”
Right now the Recruiter can review, change or delete and these activities can be finished.
On the contrary, if you wrote a story “A Recruiter can manage job offers”, the story would not show the result. Hence, using the word “manage” won’t help you write closed user stories.
How to write user stories in Da Vinci style and slice them like a cake
Stories are mostly used in iterative and incremental development. Iterative means performed in iterations (timeboxed period of time, e.g. two-week-long iterations). Incremental means with a cumulative result.
In fact, most of the artists from that time did.
On the picture below we can see that the sculptor worked in 4 iterations. Let’s call them Sprints. After each Sprint, the sculptor could inspect what was Done, ask his client for feedback and adapt the sculpture to the feedback. The result from Sprint 4 is a combined effort from all the previous iterations.
User stories aren’t written in stone. Sometimes your Development Team can suggest that a story is too large to fit into the Sprint. Don’t be afraid to split the stories into smaller ones or even merge some of them if needed. Just make sure you do it with your Development Team.
Why not alone? Because each story needs to have a little bit of each technical layer in order to provide small but end-to-end functionality. You can achieve that by slicing stories like a cake!
If you haven’t done it yet, use these two useful cheat sheets below:
- How to split user stories by Agile for All
- Breaking down user stories a cheat sheet by Christiaan Verwijs / The Liberators
The approach is very similar to Da Vinci’s. As a paint artist, he wouldn’t slice his tasks by the technicalities like e.g. “add base paint to the canvas”, “add yellow dye”, or “create the outlines”.
He would slice them this way:
Create the head
And this is more outcome style.
Takeaway: Great user stories equal great communication
It’s not easy to write great user stories. Perfect communication is crucial here, otherwise, you could end up with something similar to this.
So how to write great user stories? Only by practising. I wish you lots of great Users Stories on your journey.