User Stories

In an Agile environment, the teamwork is divided into small pieces called User Stories. It helps with the Sprints planning. Read this article to understand how to write User Stories.

What Is a User Story

A User Story (US) is the smallest chunk of work in an agile framework. It divides a large amount of product functionality into smaller functional increments that should be finished in one sprint. This practice helps with sprint planning and estimating the time spent on development. User Stories are usually building blocks of a larger agile framework, such as epic or feature. Scrum Master watches over the US life cycle. The US are useful for everyone (for example, an analyst needs them for a product description, a tester reads them to know what has to be tested).

How to Write a User Story:

• User Stories are usually written by a Product Owner who also defines the prioritization.
• A US is just a few sentences written in a simple language without going into detail.
• They follow a simple template, such as: "as a <type of user>, I want <some goal> so that <some reason>".
• Work is divided into US during backlog refinement (formerly grooming) where the team estimates stories and assign story points.
• A US can be written on a post-it note and stick it on a board, or created in software.
• US have to be testable. Even if your US are divided into smaller US, each US has to be testable.
• It is recommended to have a specific hierarchy - US are usually roofed by an epic. US can be broken into smaller chunks of work, such as tasks or features.

Four important US phases:

1. Initiation
2. Grooming
3. Planning and estimating (in which sprint the US needs to be done?)
4. Implementation

What Are Story Points?

• Story points (SP) define the effort needed to implement a US.
• A US with 2 SP should require twice as much effort to finish it than a US with 1 SP.
• Every team has to decide what SP mean to them regarding the complexity of their project.
• It takes time to settle the value of SP - the team has to compare previous experiences.

Why You Might Want User Stories

Why not just break the epic into steps? Why bother with creating the User Stories? User Stories offer the following benefits. User Stories:

• are simple and fast to write. It is beneficial for the user because they do not need to understand any specific technical details. It also helps them to express their needs in a simple language.
• give the team context and associate their work with the value of their effort.
• keep the focus on the user. By breaking down user needs (= User Stories) into smaller features or tasks the team can better concentrate on solving small and immediate customer needs.
• allow easier collaboration among the team, the Product Owner and users. They discuss and review all the US every sprint planning meeting. That encourage the team to approach their work and the goal achievement critically and creatively.
• allow the team to prioritize more easily. When the US are added to the product backlog, the Product Owner can prioritize the more important US.
• allow you to track the project development and every closed US is a an achievement which brings a satisfaction.

Problems User Stories Solve

• Demotivated team
• Increased cost
• Meaningless work
• "Not my problem" mentality
• Unnecessary features
• Unhappy clients
• Disconnect Between Business and IT
• Toxic Team Culture
• Poor Code Quality

How to Implement User Stories

The Product Owner (or a Product Manager, or a Program Manager) writes the User Stories and submits them for review. The review can be done by all the team members. Each team member decides which US they will take during the sprint planning meeting. The next step is discussing the US requirements that are added to the US. An important part of sprint planning is estimating the story points. The team can use visual planning tools (such as release plan, story map, or a task board) where they stick post-it notes with each US.

Source: Using A Task Board

Common Pitfalls of User Stories

• The US are too big The functionalities are not easy to implement and they are moved from sprint to sprint. This can bring a Toxic Team Culture because it feels like the work is never finished.
• The team mistakes the story points with the time estimation The points are there for easy comparison of the US difficulty. They do not say how long it will take to implement.

Resources for User Stories

• Agile Alliance: User Stories
• Martin Fowler: User Story
• Atlassian: User Stories
• Agile Modeling: User Story
• Product Plan: Backlog Grooming
• Scrum Study: Scrum Phases And Process
• Agile Alliance: What Is Story Mapping?