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.
The most common user story Patterns are: As a Persona, I should be able to do something so that I get this benefit OR In order to receive benefits as a role, I can goal/desire
However, there are many attributes of a user story that defines and make them:
A Unique ID
To identify a requirement uniquely. When an ALM tool is used, this attribute is set by default by the team for each requirement.
Summary
This is the short name/summary/ title of the requirement
Description
This is the user story as given in the user story format
Acceptance Criteria
These 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.
Estimation
Every user story is estimated in Story points which is the standProgressard metric in Agile projects.
Status
This indicated the completion stage of the user story- It starts from Idea (single line usually) to Defined, Refined, Planned, In progress, Completed, and Accepted.
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
A good user story is written in one to three lines
A good story should always be in the active voice
User stories are used to communicate. So make them visible and accessible
Tips for Writing Good User Stories
Keep your user stories clear and concise
Write user stories collaboratively
Start with Epics
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.
Prepare for success with our comprehensive PMP prep course. Our expert instructors and study material will help you ace the exam and enhance your project management skills. Enroll now to advance your career and achieve your goals.
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.
Lindy Quick
Blog Author
Lindy Quick, SPCT, is a dynamic Transformation Architect and Senior Business Agility Consultant with a proven track record of success in driving agile transformations. With expertise in multiple agile frameworks, including SAFe, Scrum, and Kanban, Lindy has led impactful transformations across diverse industries such as manufacturing, defense, insurance/financial, and federal government. Lindy's exceptional communication, leadership, and problem-solving skills have earned her a reputation as a trusted advisor. Currently associated with KnowledgeHut and upGrad, Lindy fosters Lean-Agile principles and mindset through coaching, training, and successful execution of transformations. With a passion for effective value delivery, Lindy is a sought-after expert in the field.
Share This Article
Ready to Master the Skills that Drive Your Career?
Avail your free 1:1 mentorship session.
Upcoming Agile Management Batches & Dates
Name
Date
Fee
Know more
Offer
Hello! Ready to elevate your career? Explore 500+ future-ready courses with KnowledgeHut upGrad 🚀x
1
Fast forward your career with 500+ future-ready courses ⏩💻👩🎓📚x
.jpg&w=3840&q=75)
