Agile is our methodology of choice, and we see how positive its impact is on our productivity and relationships in the team. User stories are its essential element and a distinguishing feature that proves its human focus. Today, we will focus entirely on them, diving deep into the theoretical fundamentals and practical aspects of creating user stories. Let’s get into it!
What is a user story in agile?
Every software project needs a thorough description which enables the team to proceed with its development and verify whether the product meets the initial assumptions. Feature descriptions are its backbone. In methodologies like waterfall, they only adopt a form of stiff, quite technical software requirements. Agile complements them with much more flexible, human-centered user stories.
A user story in agile describes a software feature that adopts the end user’s perspective. Contrary to traditionally understood requirements, user stories do not focus on technical aspects but on the value provided to the customer by the particular feature. They are brief, simple, and written in a way that allows every member of the agile development team – from the Product Owner to developers and testers – to comprehend them. Plus, they focus on the expected effect, not on the way to achieve it.
User Story lifecycle
The life of a user story may differ depending on which agile methodology we are referring to.
In the case of Scrum, user stories taken from the backlog become an integral part of each sprint. They pass from to do to in progress when the team is working on them. Once they meet the acceptance criteria, they are considered done and wait for a deployment to a production environment. On the way, they may be considered incomplete and turned back to the previous stages.
Kanban approaches the user story lifecycle a little differently, taking the user stories from the backlog once and conducting them throughout the whole software development process.
Why User Stories? Benefits
As we have mentioned, every user story captures the value the particular feature brings to the customer. It helps the whole team look at the project from the end user’s perspective. It’s the customers who, in the end, decide on the product’s success on the market. Thus, implementing user stories that filter the feature through their lens maximizes the chances of succeeding. Now that the digital market is becoming more user-oriented than ever due to increasing competition, engaging them in the project backlog provides the companies with an advantage.
Clear, simple, and non-technical user stories make it easier for the whole team to understand the goals and concepts of the project. Once they know they are on the same page, they can focus on collaborative work that will bring them closer to fulfilling these goals.
User stories in agile can serve for acceptance testing during the implementation phase, helping the team verify whether the feature works the way the end user expects it to work.
Another benefit that often passes unnoticed is user stories’ structural role. It divides the conceptualization and development of the software into smaller units, making the team actually feel the progress. That may have a tremendous motivational value.
How to create a good user story in Agile?
As usual, we would like to underline that there is no universal formula that will make your user story perfect. By definition, it is a flexible form, so you can adopt different approaches to writing it. One thing is for sure – you should avoid technical language that only a bunch of developers will understand.
Write in a simple, understandable way, avoiding relative clauses and ambivalent expressions that could have different interpretations. It’s an art to write user stories that are crystal-clear for every person involved in the project. But with time, you’ll get better at it! And as their form improves, you will see the user story lifecycle shorten, and the features – get even more user-oriented.
Nevertheless, there are some rules that you can incorporate into your writing to make your user stories better. Here are some examples of commonly used principles that you can validate your user stories with.
The “INVEST” principle
You have to invest much effort into writing a good user story. But the INVEST principle can make it easier! The acronym comes from the first letters of the features that describe a good user story. It should be Independent, Negotiable, Valuable, Estimable, Small (in terms of content and execution – it should be doable in one sprint), and Testable. You’ll find a broader definition of this principle on the official Agile Alliance website.
The “3 Cs” principle in Agile
Another principle we want to recommend to you as a way to make your user stories more complete is the “3Cs”. It complements the previously mentioned INVEST, providing you with a more practical perspective on this crucial agile unit. While INVEST focuses on the exemplary user stories’ features, this principle emphasizes their execution. The Cs stand for cards, conversation, and confirmation.
- “Cards” captures the way the user story should be developed to bring the best outcomes. User stories tend to be described on cards – not necessarily physical. If preferred, the team can, of course, use the post-it notes, but the most common way is to actually write the digital cards in Jira. With the software development and its features, the team can look up the previous stages on the cards instead of writing things down from the beginning.
- “Conversation” refers to the collaborative aspect of user stories. Even if one person is responsible for them (in Scrum, it is the Product Owner), all the team members should be involved in their development, discussing, and exchanging ideas. Cards are the drivers for the discussions, to keep conversations focused around them and build common agreement.
- “Confirmation” defines the finish line of the user story. It means settling acceptance criteria (definition of done) that must be met to consider a user story complete.
Agile user story template and examples
Bartosz Babiński
Head of Projects
The process of writing and refining stories is an ongoing activity. The goal is to create a common understanding of why we build the feature, how to build it and when we would know it is done. With those 3 perspectives in mind (business, development, quality assurance), we can create the greatest business value. Sometimes we use DoR (Definition of Ready), which defines which elements should be included in a story to consider it ready for implementation. This simple contract/checklist improves team cooperation and the final outcome.
There is no better way to understand a concept than through a practical example – the user stories themselves prove that! Let’s thus take a look at user story samples, starting with the basic template.
You can limit yourself to it if you feel it captures the complexity of a particular feature, which is not always the case with bigger projects. As a (1} I want to (2} So that the (3) template (Connextra format) enables the teams to define it precisely in the briefest form. What to fill the blanks with?
- [who] wants to accomplish
- [what] they want to accomplish
- [the purpose]
For instance: as a project manager, I need to communicate the progress to different customers at the same time so that each of them feels taken care of.
It is essential to include the acceptance criteria, which verify the assumptions of the user story. It usually goes as follows: Given that (1) when (2) then (3). Here, the gaps refer to:
- The context in which the action takes place
- the action
- the outcome
This template will help you express the feature briefly and precisely. It is only a starting point for many companies that prefer more extensive descriptions. Some teams expand the user story templates with epics (the large body of work within particular user stories are categorized) or themes (even larger units). You may also involve priority, estimation, and release to keep your user story even more elaborate. The template may also include non-functional requirements, benefit hypothesis, and cost of delay.
How to work with user stories?
In a perfect scenario, the user story passes a straight path to being confirmed and gets closed within an iteration. Sometimes, however, it turns out that it requires splitting, clarification, or completion. It is worth being prepared for such situations. You may want to skip them to avoid delays, but in the end, sacrificing some time and effort to polish your user story is always worth it.
Let’s underline once more: a better user story equals more chances of succeeding on the market!
Organizing User Stories with Story Map
User story mapping is an essential element of agile project development. The user story map helps the team define the feature and prioritize the tasks within its frame. It is particularly helpful with the complex features that will likely scale in the future.
The map captures the user journey in a segmented way, including activities, steps, and tasks (or details). It may adopt different forms depending on the complexity of the feature and the tools you use. Teams often use Jira or Miro to create user story maps, and some rely on physical resources.
To illustrate it, let’s look at a couple of real-life examples.
When to split Stories?
Splitting is a good idea whenever you cannot tell with 100% certainty that the user story will fit into an iteration. Dividing it into smaller tasks reduces unnecessary stress and allows the team members to focus on smaller portions of work. That will likely improve the work dynamics and the results themselves.
The more extensive the story is, the more likely you will need to split it, but before you do it, ask yourself if a story meets the requirements of the INVEST principle after each split.
How to split Stories?
Here, again, there is no universal recipe. Splitting may require bringing the whole team together and discussing the current shape of the user story and potential splitting possibilities. The crucial thing is that the user stories still deliver business value even after splitting. Try to keep the balance and avoid making the users too small.
When to combine Stories?
In order to know whether the story should be combined with others, it is worth coming back to the INVEST principle. If the story:
- is not releasable on its own (independent)
does not provide value on its own (valuable)
is too small for testing (testable)
…it may be worth thinking about combining it with the others. The stories you choose to combine should have a common core. In the larger Scrum projects, you will likely operate with epics – then, you first look at the stories within one epic category when searching for combinations.
Who should be responsible for writing user stories?
In Scrum, the Product Owner is responsible for user stories throughout all their lifecycle. PO writes the stories, confirms them, and splits them, making sure that they are understandable to everyone on the team. Other team members (developers, testers, UX designers, etc.) are involved in creating user stories to some extent, as they are the ones who work with them during sprints.
If you need support writing user stories, splitting them, or any other user-stories-related aspect, we would love to help! We can join you in the process or help your team get more fluent in user stories-related work with our tailor-made workshops. Reach out to us to discuss the details of your project.