agile top banner

Powerful Tips for Writing the Best User Stories in Scrum

Read it in 10 Mins

Last updated on
07th Jul, 2022
04th Jan, 2019
Powerful Tips for Writing the Best User Stories in Scrum

The main reason most projects move to Agile is they would like to see results fast. These result cannot be achieved quickly if there is a lack of clarity on the outcome, this is where user story comes in. You might also find it interesting to read the article user stories examples.

User stories are like mini single line business requirements which tell you the Who for, Why and What to develop. Requirements in Agile are written in a story format and not in name-value pair format either - this is because when you read a story you understand better.

Also, check out the detailed article on Product Owner Responsibilities.

It is easier to understand :
“As a user logging into the application the first time, I would like to be displayed help popups
When compared with:
Users: New login
What: Pop up guide.
so that I can understand the layout of the screen better”Why: Guidance.

In Agile all business requirement should be expressed in user story format, and any requirement which cannot be documented in this format is probably not a business requirement or they do not have a value.format,

Who owns and who documents User stories

 There has never been any confusion about who is responsible for a User story - It is the Product Owner. But there are often doubts about who can write them - And the answer is “Anybody”. Anybody who has clarity on the requirement can add details in, usually, if there is a Business Analyst in the team, they would document requirements, and in other teams the team member documents them. In the end, the Product owner should, however, review and accept them.

Anatomy of a User story

 The user story has elements which have to present and is usually documented in the pattern given in all Agile projects. This helps in bring in uniformity and the structure ensures that none of the components that make a story so powerful is a lot.

The most common user story Patterns are:
As a  Persona I should  be able to do something so that I get this benefit
In order to receive benefit as a role, I can goal/desire

However, there are many attributes of a user story which define and make them: 

A Unique IDTo identify a requirement uniquely. When an ALM tool is used, this attribute is set by default by the team for each requirement.
SummaryThis is the short name/summary/ title of the requirement
DescriptionThis is the user story as given in the user story format
Acceptance CriteriaThese are the details and the actual content of what is to be developed to achieve the end result.
There are many formats for writing acceptance criteria, and it could also be just single line criteria. The important point to note is, that if it is not in the acceptance criteria, it is not to be developed.

EstimationEvery user story is estimated in Story points which is the standProgressard metric in Agile projects.
StatusThis indicated the completion stage of the user story- It starts from Idea (single line usually) to Defined, Refined, Planned, In progress, Completed, Accepted.

When user stories are displayed on Storyboards they are often displayed on Post It notes and referred to as Story Card or just “Cards”.

This card displays basic and yet enough information to start a discussion :

Writing User Stories

A user story is only as effective as the discussions on them, and they are only as effective as the participation. Having ceremonies such as Refinement sessions or Amigo sessions is the what makes user stories effective. A user-story written in the correct format is the biggest step, and the next step is getting the acceptance criteria clearly documented. 

Characteristics of user stories

  1. A good user story is written in one to three lines
  2. A good story should always be in the active voice
  3. User stories are used to communicate. So make them visible and accessible

Tips for writing good user stories

  1. Keep your user stories clear and concise
  2. Write user stories collaboratively
  3. Start with Epics
  4. Refine the stories until they are ready

User stories acceptance criteria:

There are many formats for documenting acceptance criteria -
Just simple sentences or
As scenarios or
As scenarios in Gherkin format (Given.. When.. Then..)
Gherkin format is especially popular in teams where Testing is automated since the Acceptance criteria can be reused, and this reduces any instance of requirement ambiguity or misinterpretation.

Acceptance Criteria Vs User Stories in Scrum

Non-Functional Requirements in User Stories

Often, non-functional requirements are not documented as stories, and they are a part of the Definition of Done (DOD). Performance, for example, should not be impacted by any story, and the development should be scalable for in every user story. These may be documented for final verification however cannot implement as a separate story.

Managing User stories

Requirements in agile projects are negotiable. They can be discussed and modified till they are in the sprint, and even when they are in the sprint when there is better clarity the requirements can be modified. To manage this change and have a central repository it is important to manage requirements in an online tool which would provide a single version of the truth.

There are multiple tools available online such as Jira from Atlassian, Rally, Rational Requirement Composer (RRC), VersionOne etc which provide a platform for managing requirements and also their lifecycle from idea to the acceptance stage.

The lifecycle of a User story

The detailing of a story card is done through multiple stages of the grooming process. These are broadly classified into 3 stages known as the 3Cs-

  •  Card – At this stage, only the purpose of the card is highlighted with no or very little details on the actual expectation
  • Conversations on the card – At this stage members from the development, test, and requirement/business teams discuss the scope of the card (in scope and out of scope functionalities) and detail out the card and also provide estimates on the card
  • Confirmation- At this stage, the acceptance criteria and tests which have to be completed to confirm that the requirement is working are added into the card

The lifecycle of a User story in Scrum

INVEST in good user stories

Writing requirements in User story format was a practice first adopted in Xtreme Programming. This was a part of involving the end users early and getting their perspective of what has to be developed. In 1998 Alistair Cockburn visited the Chrysler C3 project in Detroit and coined the phrase "A user story is a promise for a conversation.". It is a business statement of what is needed and why. However for the user stories to become effective it is also important that they follow some best practices so that the business and development teams have a common guideline.
These guidelines are referred to as the INVEST criteria, where INVEST is an acronym for :

INVEST in good user stories in scrum

  • "I" independent (of all others) - The story can be worked on independently and shown to the end user - all dependencies are completed and no longer a blocker
  • "N" negotiable (not a specific contract for features) - Stories should be the starting point for conversation and they should not be treated like a contract negotiable.
  • "V" valuable (contract negotiable or vertical) - They should provide value to the end user. 
  • "E" estimable (to a good approximation) - Only stories which are clear can be estimated, and in agile estimation are the best understanding guess based on the relative size.
  • "S" small (so as to fit within an iteration) - Story should be sized appropriately. They should not be too small or too the big.
  • "T" testable (in principle, even if there isn't a test for it yet) - If there is a value expected from the story it should be testable and validated as delivered stable.

Why do other requirements still exist if this is so good?

  • User stories are starters for conversation and so they are preferred in projects where the Product owner is available for discussion. When the presence of a business member is not possible for the team all through the sprints, it could be difficult to have User stories as requirements.
  • User stories do not tell you how to develop - They just tell you what and why. If the team is new to the technology, user stories might not be good enough and the team would need a lot of support and guidance from experts to start the implementation.
  • Often user stories are misunderstood as being flexible even during implementation and team implement more than documented- unless guided well the technical implementation could be impacted.
  • Sometimes writing a user story can be tricky and time-consuming. User stories have a simple single sentence template, and are supported by acceptance criteria - and the acceptance criteria could depending on the maturity of the team become a binder or be treated as a contract by the members making it extremely difficult for the person documenting them. 


Agile projects have requirements documented as User stories and approved by the Product owners, and with a self-motivated team which is aware of the business goals working on them, User stories trigger the right conversations leading to best designs.


Tanisha Joseph

Blog Author

Over 11 years of experience in Agile projects. Experienced Agile first hand as a Team member, Business Analyst, Scrum Master and Agile coach. Through her career she has been a part of projects in Banking, Tourism, Media and Networking domains. Strong advocate of being Agile in Agile projects, and experimenting to find whats best for the team.