User Story Best Practices: Tips to Write Best User Stories in Scrum

The main reason most projects move to Agile is they would like to see results fast. These results cannot be achieved quickly if there is a lack of clarity on the outcome, this is where the user story comes in. You might also find it interesting to go through 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. Go for CSPO certification training and advance your knowledge with an experiential learning format.

Who Owns and 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, 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 that have to be present and is usually documented in the pattern given in all Agile projects. This helps in bringing in uniformity and the structure ensures that none of the components that make a story so powerful is a lot.

However, there are many attributes of a user story that defines and make them: 

When user stories are displayed on Storyboards they are often displayed on Post-It notes and referred to as Story Cards or just “Cards”. This card displays basic and yet enough information to start a discussion :

Tips for Writing the Best User Stories in Scrum

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 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.

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 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 that 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.

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 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 to the card

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:

• "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) - The story should be sized appropriately. They should not be too small or too 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 User Story is 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 implementation 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. 

Conclusion

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