Introduction to Scrum User Stories | David Tzemach
Updated: Mar 3, 2022
Once stakeholders decide that new development is needed, the Agile process begins. The Product Owner (PO) translates customer requirements into a clear vision of what the new software will do and what service/solution it will provide.
This practice is not unique. It is relevant for both traditional and Agile frameworks, with one significant difference related to the “process” of translating customer requirements. In traditional methodologies like “waterfall,” the translation produces a heavy SRS/Spec containing all the requirements. Creating large, rich documents is not suitable for Agile software development.
In Scrum, the Product Owner uses a lightweight approach, capturing the requirements in the form of User Stories.
User stories are one of the core components of Scrum. They help create a user-focused framework to guide the team’s work. This method increases collaboration, synchronization, and creativity among team members, which are all essential ingredients.
User Stories Explained
A user story is the smallest unit of work in the Scrum framework (Tasks are smaller but only serve the team). It provides a way to express a software requirement in a readable and structured form. It is written from the software user’s perspective.
The most crucial goal of a user story is to deliver the specified value to a particular customer. A necessary clarification is that "customer" can reflect either internal customers (within the organization) or external customers (paying customers outside the organization).
Compared to traditional requirements documents containing thousands of sentences, user stories are relatively straightforward and are just a few sentences written in simple language. Each story outlines the desired outcome without getting too deep into detail. This is why they are used within Agile frameworks like Kanban and Scrum.
Template for Writing User Stories
There are different ways to write stories. Depending on the platform used, you also choose TFS, Jira, or even a simple sticky note. Stories are often expressed in a simple structured format like this: As a <User>, I want to <Description of the action, goal or objective>, So that <I will get this benefit>
Further breakdown:
As a <User> – Who are we building it for? Who is the user?
I want to <Description of the action> – here we describe what the user is trying to achieve. In this part, you must focus on their goal and intent to allow the team to understand the scope of work.
So that <I will get this benefit> – This section should provide clear answers for “why are we building it?” and “What value will it bring to the user?”
For example, user stories might look like these:
As a sysadmin, I need access to the main server to modify user permissions.
As a customer, I want to access my account from a remote location, so I will be able to work outside the office.
As the team manager, I want to create a presentation that will summarize the project to demonstrate how the team performed.
Standard Fields of User Stories
The basic template of a user story covers little of what the team should do once development has started. This is why user stories should have another layer of information based on these standard fields:
Creator/owner – The creator of the user story can be any team member.
Unique Identifier – Each user story should have a unique ID that allows the team to identify it in a product backlog with hundreds or even thousands of stories.
Related hierarchy – Each user story is driven from a higher hierarchy, such as an Epic or Feature that gives the context to understand the story.
Related Tasks – Each user story should include related tasks that guide the team throughout the sprint.
Acceptance Criteria – Conditions of satisfaction from an end-user perspective.
Dependencies – All product parts will be influenced by developing/not developing this story.
Priority – The priority of the story compared to other stories.
Effort Estimation – The team determines the effort it will take to deliver the story.
Technical information – Any technical information to help and guide the team throughout the development process.
Who Can Write User Stories?
It is the PO’s responsibility to gather and manage user stories. However, the Scrum development team and other stakeholders can also create stories of their own (in coordination with the PO).
Who Is the Story Owner?
Simply put, the PO is the owner of the stories located in the product backlog. Once they are added to the sprint backlog, the development team commits to fulfilling and owning the execution and delivery of each story.
Benefits of User Stories in Scrum
There is no doubt about the importance of user stories in the Agile environment as they provide several key benefits:
Simplicity that establishes a common language
User stories are fast and straightforward to write. Both the customer and the team can describe the exact requirements (functional and non-functional) without using the long exhaustive description of requirements and technical details. Stories create a common language among the different stakeholders that they can now reflect their real needs.
Written based on customer requirements
All functional stories are written from the perspective and expectations of the customer. This allows development teams to deliver the customer's exact product without hidden assumptions.
Easier for the team to prioritize
Once the user stories are added to the product backlog, the PO and the team can understand which stories are more important to the customer. It also allows them to understand which stories they should deliver first to meet customer expectations.
The use of stories fosters collaboration.
Due to their simplicity, user stories make productive collaboration easy among the project stakeholders. This is contrary to traditional teams who rely on exhaustive documentation that defines all requirements for the project up-front.
The world in the palm of your hand
Stories contain all the information the team needs to start implementation. They enable development teams to deliver real customer value without searching through data located in one central document.