Back to: User Story
What the tool is
Each unit of work is assigned a user story in an agile framework. It expresses itself as an objective from the software user’s perspective, not as a feature.
The user story is a short, informal statement that describes the functionality of a software application from the perspective of the customer or user.
Users are intended to benefit from a user story by showing how the piece of work will be beneficial to them. In addition to external end-users, the term “customer” can refer to internal customers and colleagues within your organization who are dependent on your team.
In simple language, user stories outline the desired result. Users are not given details, and requirements are added later.
Storytelling works well with agile frameworks like scrum and kanban. User stories are written down during sprints so that they can be refined over time. Kanban teams use a backlog to collect user stories and a workflow to process them. User stories help scrum teams estimate and plan sprints more accurately, resulting in increased agility and forecast accuracy. Kanban teams benefit from stories by learning how to effectively manage work-in-progress (WIP).
A bigger agile framework may also include epics and initiatives in addition to user stories. An initiative consists of multiple epics that are broken down into stories. Through these structures, the development team contributes to the goals of the organization via its daily work (on stores).
What are in the user stories?
Write user stories by considering the following:
- Definition of “done”: The story is considered complete when the user has completed the outlined task, but make sure that this is clear.
- Outline subtasks or tasks: Choose which specific tasks need to be carried out and appoint the people who are responsible for them.
- Personas: Who are they for? Consider creating multiple stories if there are multiple end-users.
- Ordered Steps: Puzzle steps together and describes each step with the story context, making sure it’s cohesive and relevant
- Feedback: Find out what your users need and what their problems are. Instead of guessing at stories, ask your customers.
The discussion of time is often avoided by development teams, instead of relying on their estimation frameworks. Stories that may take weeks or months to complete should be broken up into smaller stories or treated as their own epic since they should be completed in a sprint.
Once the user stories are clearly defined, make sure they are visible to the entire team.
How does it help the agile team?
Once a story has been written, it’s time to integrate it into your workflow. Generally, a story is written by the product owner, product manager, or program manager and submitted for review.
During a sprint or iteration planning meeting, the team decides what stories they’ll tackle that sprint. Teams now discuss the requirements and functionality that each user story requires. 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 common step in this meeting is to score the stories based on their complexity or time to completion. Teams use t-shirt sizes, the Fibonacci sequence, or planning poker to make proper estimations. A story should be sized to complete in one sprint, so as the team specs each story, they make sure to break up stories that will go over that completion horizon.