upGrad KnowledgeHut SkillFest Sale!-mobile

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

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

Published
30th Sep, 2024
Views
view count loader
Read it in
10 Mins
In this article
    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.

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

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

    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) - 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.
    " style="height: 402px;">

    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.

    Frequently Asked Questions (FAQs)

    1What is an example of a user story best practice?

    User story best practices include keeping the user story light and open for discussion in the backlog refinement, utilizing visual representation over theoretic phrases, detailing acceptance criteria to ensure right understanding of user requirements. 

    2What are the 5 components of a user story?

    The 5 components of a user story are also the 5 W’s that define the content and details of the user story, viz. Who, When, Where, What and Why. The 5W’s help determine a user story format to ensure completeness and objectivity behind the same.  

    3What is the formula for a user story?

    Considering its lightweight nature, agile does not have a hard and fast formula for the user story and indeed these can differ according to the project/situation needs. For example, some teams may follow the 3C format/formula (Card, Conversation, Confirmation) while others may follow the 5 W's as listed above.  

    Profile

    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
    User Story Best Practices: Tips to Write Best User Stories in Scrum

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

    Select
    Your Message (Optional)

    Upcoming Agile Management Batches & Dates

    NameDateFeeKnow more
    Course advisor icon
    Offer
    Whatsapp/Chat icon