User stories: writing them for Agile and Scrum

In order to prioritize the development tasks in Scrum, it is very common to use user stories. User stories describe a certain action by the user of the software that has business value. And thereby help the team visualize and strive for the end result. As well as prioritize tasks that lead to that result. 

User stories can take several forms. Here are some of the most common examples. First of all, according to Mike Cohn, the most common one describes an action by a user, and is written as follows:

What are agile user stories?

A user story is the end goal, expressed from the software user’s perspective. It doesn’t define a specific desired feature, but rather alludes to the desire of the user itself.

For instance, a user story would not claim “As a project manager, I want my PM software to be equipped with Gantt charts and burndown charts to be able to track project schedules”. It would rather say: “As a project manager, I want to have the long-term work progress of my team visualized so that I could track project schedules”.

Once the “I want” section in a user story is finalized, the development team can start reflecting on concrete ways to achieve this user’s goal. This is where they go into detail on requirements and features.

User stories are usually a few sentences in a simple, general, and informal language that define the desired outcome of a development stage.

Stories fit swiftly into Agile methodology frameworks like Scrum and Kanban, and are visualized on Agile task boards. In Scrum, we add user stories to sprints and they “burn down” over the duration of the sprint. Kanban teams pull user stories into their backlog and drag them through their workflow. It’s this work on user stories that help Scrum teams get better at forecasting and sprint planning. Which leads to greater agility. Thanks to stories, Kanban teams learn how to manage WIP and can further adjust their workflows.

User stories are also the building blocks of larger agile units like epics and initiatives. Epics are large work items that can be broken down into a set of stories. Multiple epics make up an initiative. These larger structures ensure that the everyday work of the development team contributes to the organizational goals built into epics and initiatives.

Agile epics

In a sense, user stories and epics in agile are similar to stories and epics in film or literature. A story is one simple narrative. While a series of related and interdependent stories makes up an epic. The same is true for your work management, where the completion of related stories leads to the completion of an epic.

Breaking down work into stories and epics can help your team communicate efficiently within the organization. If you were reporting your team’s progress to the Head of Engineering, you’d be speaking in epics. If you were talking to a colleague on your development team, you’d speak at the story level.

Agile initiatives

In the same way that epics are made up of stories, initiatives are made up of epics. Initiatives offer another level of organization above epics. In many cases, an initiative compiles epics from multiple teams to achieve a much broader, bigger goal than any of the epics themselves.

Agile themes

In many organizations, the founders and leadership teams will put forward the pursuit of some broader destination. These are the goals that the leadership board announces each year or quarter, and themes are how you keep track of them. In other words, themes are labels that track high-level organizational goals. They are an organizational tool that allows you to label backlog items, epics, and initiatives to understand what work contributes to what organizational goals. These goals can be “Security first”, “Sustainability” and others.

How to write user stories?

There are a couple of templates floating on the internet to help you write a user story. In fact, if you want to write good user stories, you need to define 3 things:

User Persona: The person who is going to use the feature. Personas are often fictional characters imagined based on real data.

The persona’s need: What the user persona wants to do, or what function/feature he/she wants.

The persona’s goal: Why he/she needs the specific function/feature and what benefit they want to achieve from it.  

It is hard to get these 3 points as close to reality as possible. You need to do research, talk to your users and understand their needs. And only then, when you collect enough data, you’ll be able to write good user stories using these aforementioned simple templates.

Who writes user stories?

Anyone can write user stories. It’s the Product Owner’s (in Scrum) responsibility to make sure a product backlog of Agile user stories exists. But that doesn’t mean that the Product Owner is the one who writes them. Over the course of a good Agile project, you should have user story examples written by each team member. Including Scrum Masters.

Also, note that who writes a user story is way less important than who takes part in the discussions around it.

When are user stories written?

User stories are written all the way throughout the Agile project. Usually, the story-writing workshop takes place when the start of an agile project is near. Everyone from the team takes part in this with the goal of creating a product backlog that fully describes the functions they will be working on in the nearest Sprints.

It is a good idea however not to plan too far ahead straight from the beginning. In other words, not to write all or the majority of user stories at the beginning of the production cycle. One of Agile core ideas is to plan only on demand. In other words, the later you plan your upcoming tasks or write user stories, the more relevant they will be. As you will propose them fully aware of the current state of market affairs, customer and stakeholder expectations. As well as having gathered more data with the more time you had to research and prepare.

The market is a factor that changes constantly. And you must stay updated and aware of the external factors to be able to set the right priorities. After all, you are selling the product to someone directly and unavoidably influenced by those factors or even the one making the change.

User stories on demand

That is way all Agile methodologies including Scrum allow space for regular re-planning and revisions of the direction of the project. This is where you get to write new user stories as well. Taking into account that the needs and requirements of users have most probably changed by that point. And writing user stories accordingly, in sync with the newest market trends.

If you are really good at this game, you can even guess the changes in market and user behavior before they even appear. And create your Agile user stories based on these presumptions. By such a tactic, if you are right, you will not even be a reactive user story creator, but rather a proactive one. However, all this requires an in-depth knowledge of the subject, your market, customer and stakeholder psychology, economics and other relevant fields. Spend your time wisely by gathering various data to make the best-informed decisions.

You need that for the end product to remain relevant to the end-user in the circumstances that he will be at when the time to deliver a product comes.

Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a single sprint. Additionally, new stories can be written and added to the product backlog at any time and by anyone.

Do user stories replace a requirements document?

Agile projects, especially Scrum ones, use a product backlog. This is a prioritized list of the features to be developed in a product or service during an iteration or Sprint. Although product backlog items can be whatever the team chooses, user stories have emerged as the most popular form of backlog items.

While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is not yet complete until the discussions about that story take place. And these user stories are agreed upon by members of the team as well as the leader.

It’s often best to think of the written user story as a hint to the real requirement. User stories could point to a diagram depicting workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team wants.

Why should you create user stories in Agile and Scrum?

Even more reasons for making use of user stories!

• Stories create momentum. With each completed story the development team enjoys small challenges and a small wins, driving momentum.  
• Stories help prioritize key functionalities. Simply asking yourself “will this bug stop my users from achieving their goal” can help you prioritize better. This same principle can be applied to an improvement or a new shiny feature knocking on your door asking to be added to your existing product. Think if the user really needs it or is it just you and your enthusiastic team that want to go over the top adding cool and advanced but essentially useless to the customer settings. On the other hand, the customer will be unsatisfied if you forget to add a crucial function that he needs for everyday use. Such prioritization will surely save you a lot of time which is a big difference between Agile and Waterfall.
• Stories focus on the problem. It’s easy to jump straight in and drown yourself in a sea of plausible ideas, rather than taking a step back and focusing on what the problem is. And why it came about in the first place. And how many users are facing it. Starting with “What” – the solution – is not necessarily the best approach to meet customer needs. But when you start with “Why” – the problem – you get to gather your team around a problem and promote creative ways to solve the problem at hand.

As Paul Graham said…

Quoting the wise words of Sir Paul Graham:

“In a sense, there’s just one mistake that kills startups: not making something users want.”

Paul Graham

So go ahead and make sure that YOU create something that users WANT. User stories are sure to help you out a ton with that.

How to work with user stories?

Once you write the user story, it’s time to integrate it into your workflow. Usually, a product owner, product manager or any team member writes a user story and, importantly, submits it for a review. Only after review, when other members of the team acknowledge the user story, it can start its implementation process.

During a sprint planning meeting, the team decides what stories they’ll take care of that iteration. Teams then discuss the requirements and functions that each user story brings with it. This is an opportunity to get technical and creative in the team’s implementation of the story. Once agreed upon, these requirements are added to the story.

Another crucial step in this meeting is to estimate the stories based on their complexity or time to completion. Teams might use t-shirt, pizza, cup or whatever other sizes for comparison analogy to make accurate forecasts. A story should be set to complete in one sprint, so as the team goes over each story, they make sure to divide stories that go over that horizon to smaller pieces.  

User story templates

Stories are often expressed in a simple sentence, as follows:

“As a [persona], I [want to], [so that].”

Explaining this in a nutshell: 

“As a [persona]”:

Who are we building this for? Let’s say this persona is Julian. Julian will stand as a symbol of a person coming from a specific field or background. That is the background of our relevant customers. However, Julian is not just a VP of sales at one of our targeted organizations. He is not a dead algorithm or function that represents a job position or status where everyone is the same. He is rather a human being with individual needs, hopes and fears. And we cannot grasp him and his motives fully thinking of him as just of a sales manager.

Our team should use their imagination to put themselves in Julian’s shoes and follow him throughout his decision making process. And try to understand his cognitive as well as behavioral cues. The team should manage to gain a shared understanding of who Julian is. They have hopefully interviewed plenty of Julians, communicated with them by other means or observed them and their digital as well as physical footprints for a long enough period of time. So the team understands how that person works, how they think, what they are afraid of, what they love, what they hate and what they desire. They have empathy for Julian. They are one with him.

“Wants to”

Here we’re describing the persona’s intention and NOT the features we imagine them to automatically desire. From the customer side there is just the intention, the need that has to be satisfied, and it is our as development’s team job to come up with viable solutions for fulfilling Julian’s needs in the most efficient and productive way possible. One that works best for Julian as well as is manageable for us. What is it he is actually trying to achieve? Once again, it is important to play pretend games here and try to abandon our own perspectives and take on his. You are missing the point if in this stage you are describing any part of the UI instead of focusing on the persona’s goal.

“So that”

How does their immediate desire to do or have something and the fulfillment of this desire fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?

So, how DO you write good user stories?

+Examples

When writing user stories, it is important to follow several guidelines to make them effective. Below is a brief overview of factors that make user stories work well for agile development purposes: 

1. Be valuable. 

User story needs to describe an action that is valuable to a specific user. If there is no inherent business value in a user story, it does not provide a rationale for a certain action and therefore is not particularly useful for the development team. For example, a user story “The user is  able to hover the mouse over a button.” carries no rationale or inherent business value  and therefore is ineffective. A much better version is “The user is able to make the payment in no more than three steps”. 

The gaps between your user’s pains and the solutions they have today are your feature’s real playground. And if your user stories aren’t going to fill in those gaps, you are better off not working on them.

2. Target a specific user. 

A common trap in writing user stories is targeting no one in particular. If you are running a business for a certain type of customers, it makes sense to explicitly state these target customers and the value they will be able to derive from using your software. For example, a CRM software company could have the following user story “As a person, I can purchase the software on the website”. This gives little information on how the purchasing process should look like. A much better version is “As a corporate purchasing manager, I am able to purchase the CRM software online with my corporate credit card and install it within 30 minutes.” 

 3. Have clear acceptance criteria. 

In order to understand whether the tasks have been completed, it is important to specify exact acceptance criteria for a user story. Therefore, vague user stories can paralyze the team, not yielding any tangible results. It is often tempting to have user stories that are abstract – e.g. “As a user, I enjoy the purchasing experience.” Such user story does not give much guidance on what tasks should be implemented in order to achieve that, and therefore is ineffective. It can be solved by making the user story more precise “As a buyer of books, I am able to find and purchase the book with no more than five steps.” Also, acceptance criteria can be specified to make sure that the user story is implemented – such as “The purchasing process supports Visa, Mastercard and Maestro.” 

4. Be testable. 

After the tasks related to the user story are accomplished, it should be easy to test whether the user story is implemented or not. A good example of a testable user story is “The app shows user’s current location on the map.” On the contrary, a bad example of a user story is “The app looks appealing to the users”. In some cases, it could be possible to aim for abstract user story – but then it has to be accompanied by a test, such as “Over 50% of the surveyed users indicate that the interface of the application is appealing.” 

5. Be small. 

User stories need to be small enough to be implemented within the sprint – depending on the process in your company, it typically means implementable within a week or two. Therefore, a user story “As a user, I can access my software on iPhone, Android and Windows Phone” is not particularly useful if you are just starting to develop the mobile version of your application. Instead, try to limit the user story to what is achievable during the sprint: “As a user, I can access the scheduling function of my software via a mobile web browser.” 

6. Be described concisely. 

Finally, the description of the user story should ideally be short and clear – so short that you can actually have it written on a post it note, or in an agile tool like Teamhood. 

Do you have any further tips on how to write effective user stories for Scrum? Share with us!

Vidas Vasiliauskas

Website

2019 - Present Co-founder and CEO @ Teamhood.
2015-2019 Head of software engineering department at Danske Bank.
2017-2018 Partner Associate Professor at Vilnius University. Lecturer of Software Architecture course
2011 - 2015 Managed numerous smaller IT teams at Prewise.
Co-founder of RaveIT, Eylean, No Brakes Games

Certified Agile product owner and practitioner. Managed large scale enterprise projects as well as launch of small startup products.
MSc of Software Engineering at Vilnius University.

Hobbies: Racing, MTB cycling, Windsurfing