Menu Close
How to write great user stories for my product
Agile Project management

How to write great user stories for my product

Posted on 20/08/2019
6 min read

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:

  • What is a user story
  • How to write a user story from user’s perspective
  • How to start writing user stories
  • How to check if a story is great or not
  • How Da Vinci would write user stories

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:

As (who?) I want (what?) so that (why?)

 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. 

write user roles for user stories

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: 

  • First Timer
  • Layoff Victim
  • Job Seeker
  • Recruiter
  • Admin

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: 

  • Search for jobs based on salary, location, language, skills.
  • Compare salaries based on position and location.
  • Automate the search with notifications which could be sent when a new or similar job is posted.
  • Easily apply for the jobs with pdf resume and LinkedIn profile.

I’ve pinned these 4 post-its below the user role as it’s shown on the picture below.

goals of job seeker post it

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. 

job seeker user flow

recruiter's user stores

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. 

The most important intent behind user stories is a fruitful conversation between people who know what to build and people who know how to build it.

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 

dilbert about create intuitive products

source: Dilbert

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 do we know when we’re done?
  • How exactly this should work?
  • What is the happy and unhappy path?
  • Are there any edge-cases?

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.

Do you know that Da Vinci also worked in an iterative and incremental way?

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. 

work in 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!

cross-functional team


If you haven’t done it yet, use these two useful cheat sheets below:

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 torso
  • Create the head
  • Add a face with a happy expression
  • Change the facial expression to angry
  • Add hands on the head
  • Change arms to crossed

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.

developer client communication

source: Cakewrecks

So how to write great user stories? Only by practising. I wish you lots of great Users Stories on your journey. 

About the author

Tomasz Kulczycki
Tomasz Kulczycki
Scrum Master / Agile Project Manager

A guy with experience in MedTech, IoT, and software development gained by helping different companies, from startups throughout corporation from Fortune 50. In his free time, he reads the agile books, cooks vegan, plays board games and takes part in agile meetups and events.

See other blog categories


Tips, trends and business insights for startups and growing companies.


Team building, team development and values that build a conscious organisation.


Top frameworks, technologies and development tips from our team.

Project management

Everything you need to know about project management to make your projects successful.

Let’s talk!

Get an estimate of your project’s time and cost.