What is a user story?

In Agile Software development, the execution level requirement or functionality is terms as user story. A user story can be of one or more sentences. The requirement (details contents) in the user story needs to be sufficient enough so that

  1. A developer can start and finish his development
  2. A tester and test the developed code to check if it is meeting the required functionality
  3. Product owner/ BA / Stake holder can verify the desired functionality to accept the story completion.

Each story has be to fulfill a requirement with a very specific goal or benefit, it’s always advisable to break any store to smaller stories, if it has more than one goal.

Requirement of a story has to be of a complete functionality, means upon completion of development, testing and acceptance, the code should be deploy-able, or park for future release. In other word the each user story should be potentially ship-able.

Size of a user story is measured in story points (Refer our section Estimation Techniques), to provide a business value or complexity.

Structure of a user story?

A good user-story contains four major segments to describe the requirements and its testing scenarios

  1. Role
  2. Goal
  3. Benefit
  4. Acceptance Criteria

A typical template of a user story is like

As a <Role> I want <Goal> so that <Benefit / Expected outcome>.

The Acceptance criteria is very crucial for a user story to use in unit testing, QA and story acceptance by product owner or Stake holders.

Understanding the 3Cs.

A well structured user story should have three sections

1. Card

A one to two liner text to written as an identifier of the user story. This can be written as “As a — I want — So that” or a plain text. this text usually printed on the story cards, that is use in a story board. Many ALM tools have a text field named Title to capture this information.

2. Conversation

This the area where the details description of the user story goes. This can be start with “As a — I want — So that”. followed by details requirement. A Detail requirement can have Screen shots , ware frames, external links etc to elaborate the requirement better.

3. Confirmation. 

This is the are of Acceptance criteria, most ALM tools provide a section to capture the acceptance criteria, if not provided, you can write your acceptance criteria at the bottom of your description with a heading “Acceptance Criteria”

A typical template of a user story is like

As a <Role> I want <Goal> so that <Benefit / Expected outcome>.

The Acceptance criteria is very crucial for a user story to use in unit testing, QA and story acceptance by product owner or Stake holders.

Backlog Grooming
Sample story structure

The first 3 segments (role, goal, benefit) are used/named differently by different practices, as below

Characteristics of a user story
A well-formed user story needs to meet the following characteristics of bill Wake’s INVEST acronym
  • I ndependent
  • N egotiable
  • V aluable
  • E stimable
  • S mall
  • T estable

Refer the below diagram to read more about the each characteristic

Example of good user story
here is an example of a good user story 

Example 1

—–

As an online visitor I want to add products in my shopping cart so that I can purchase multiple products at one go.

Acceptance Criteria [Abstract]

Products can be added to the cart

Products can be removed from the cart.

Shopping cart will be empty initially

Shopping cart will be empty after purchase

Products can be added with multiple quantities in the cart

Shopping cart will show the total product breakdown quantity and cost with grand total

Example 2

—–

As an online visitor I want to add products in my shopping cart so that I can purchase multiple products at one go.

Acceptance Criteria [Elaborated]

1.Given my Shopping cart is empty
When I add a product to my cart
Then my shopping cart should contain 1 quantity of the added product

  1. Given my Shopping cart contain 1 product
    When I add the same product to my cart
    Then my shopping cart should contain 2 quantity of the product, and I can see a warning the product has more than one quantity.
  2. Given my Shopping cart contain 1 or more product
    When I click on delete button inside cart page for any specific product
    Then my shopping cart should remove the deleted product and show the remaining product in the cart
  3. Given Shopping cart contain one or more product
    When click on confirm order on cart page
    Then My shopping cart should go empty after successful order
  4. Given shopping cart contain one or more products
    When Open Cart page
    Then It Should show all the products break down with its selected quantity and cost and appropriate totals of cost and quantity
  5. Given shopping cart contain one or more products in Cart page
    When change the quantity of any product  Then the product’s cost should be updated and subtotals of quantity and cost should change accordingly
Attachments:

Wire frame of Cart page is attached.

End of Section Structure of a user Story

Associations of user story

In Agile software development, we understood what is story and its structure, now we will learn the associated members of a story in Agile life cycle. There are two main type of association, One to One and One to many, as below.

One to One relation with user story and associated information
  • null

    Story ID

    A unique identifier of the user story. traditionally the number used to be like Epic Number.Featurenumber.StoryNumber (e.g. 1.3.1, 1.3.2, 1.3.5, 1.4.1 etc). how ever many ALM tools like Jira, Rally generate the number automatically on creation of new user story. those number can be sequential incremental number for the organization, or can be sequential number prefixed by alphanumerical value to represent groups, projects etc (e.g. ABC123, ABC124, FIN245 etc)

  • null

    Story Title

    An one liner sentence to represent the whole user story, for easy reference and discussion. A meaningful crisp text to symbolize the requirement. A title for the user story mentioned as example on above section could be “Adding product to cart”

  • null

    Story Rank

    A number to represent the priority of the story in backlog, the lowest number appears at the top of the backlog. to pick for grooming/planning etc. Product Owner or Business Analyst or some time stake holder takes the responsibility to prioritize the backlog by rearranging the rank according to the priority of execution.

  • null

    Story Description

    This is the section where the details of the requirement get captured, Its consist of Role, Goal, Benefit, Acceptance Criteria, attachments, as mentioned under “structure of user story” section. This section get changes to mature up the requirement by product owner or BA or Stakeholders, The section is advisable not to change after the story is groomed and estimated.

  • null

    Story Points

    Story points are the measurement unit, to represent the size of a user story in terms of business value or complexity. will discuss on details about story point in Estimation and planning section. The possible values should 1,2,3,5,8,13,21,… in fibonacci series, This is also called as relative sizing.

  • null

    Story State

    In the life cycle of a user story, it goes through mane stages from its initiation till deployed to production or ready for deployment. The stages are not fixed it can be customized based on organization need. the basic flow is shown as below

    The Good example of workflows for the stages of User stories are also available as below which break down the stages in smaller and better track able units

  • null

    Blocked or Impeded Status

    The Status of the user story to mark it as blocked or impeded and causing delaying its movement in its life cycle.

    The possible values are [Yes / No ] or [True / False ] or [Blocked / Not Blocked]

    majority of the time a story get blocked during its in-progress stage

  • null

    Blocked Reason

    Description with the reason for the blockage if any story is blocked or impeded, possible examples are

    • Cross functional team has not completed their user story marked as our story’s Predecessor
    • Task assigned to UX, has not yet started working, delaying dev work
    • Test data not available to do a unit testing
  • null

    Parent

    Agile User stories need to be well organized to track the product increment on each level of senior management or portfolio, Each user story can be a child of a feature.

    Many practices create sub user story by making another user story as parent, which we advice to avoid if possible.

    Will learn more about User story and its hierarchy, later on this page.

  • null

    Release Information

    This information contain the release number its is planned for, Its an optional information, can be added at any stages of its life cycle.

  • null

    Sprint Information

    This information contain the Sprint or iteration number its is planned for, The scrum Master updates the information as soon as the story was committed for a sprint in sprint planning meeting.

  • null

    Owner

    Information of the person who created the user story, or currently owning the user story. he is the person responsible for accepting the user story.

  • null

    Assigned to

    Usually tasks are assigned to developer or tester, but many practices do not use task. They keep on changing the assigned-to information with the team member’s name to marking who is currently working on the user story, The Developer , or the tester, or the product owner for verification and acceptance.

  • null

    Project Code

    Optional value to map user stories with some project code or cost center for other management purpose.

One to Many relation with user story and associated information (Optional)
  • null

    Child Story

    Few Organization or practices create sub stories or child stories under one user story, we personally advice map stories with feature as parent for better mapping and tracking.

  • null

    Task(s)

    Tasks are the bottom most layer in user story hierarchy, and always child of user story. You can create smaller tasks under each user story to estimate the efforts in hours based on the task assigned to resource skill level. example of tasks are

    Development, Database Design, UI Design, Testing, ….

    Remember the effort estimation on tasks are man hours, it has no direct relation with story points

  • null

    Successor(s)

    Successors are the dependent story(ies) linked to your story. The successor story(ies) can only start its development once your story is complete.

    for example

    Your story : Import Test data for Online purchase functionality

    Successor story : Online Purchase functionality enable add product to cart

  • null

    Predecessor(s)

    Predecessors are just opposite of successors, This is also part of story dependency. You can only start working on your story once the predecessor story(ies) are completed.

    for example

    Your story : Online Purchase functionality enable add product to cart

    Successor story : Import Test data for Online purchase functionality

  • null

    Discussion(s)

    Discussions or threads of comments on each story between Team Members, Stake holders, External team or dependent team. to capture and keep a note on discussions happened during the different stages of a story.

  • null

    Defect(s)

    You can map one or many defects to each story to keep a track of defects raised by the testers during testing or verification stage, optionally you can provide option to mark priority and severity of defects, with status like Open / Resolved  / canceled etc.

  • null

    Test Case(s)

    You can also create and map one or more test cases to your story

  • null

    Attachment(s)

    Product Owner or Stake holders or BA or any one can provide attachments to enhance the requirement, also testers can attach test results as a proof of testing passed or fail status.

  • null

    Tag(s)

    You can map or add one or more tags to your stories, for customize your reports or filtering the stories on your custom category

End of Section Association of user story

Who can write or update user story?

Product Owner is primarily responsible of the contents of user story. Some places the Business Analyst also get involved to write and take the responsibility of user story contents. Team members can help product owner or BA to write user stories, but as product owner or BA understand the business requirements and acceptance criteria better than any other team member its always a good idea to leave this responsibility with product owner or Business Analyst.

Once Initial Draft is created, Product Owner or BA can enhance the requirement from the input from Team member or external resource, captured during Grooming

How ever there are instances of creating Spikes ( Will discuss about spike later in this page), Developers, Testers, UX team member etc can write those special types of user stories

When user story can be written or update

User Story can be written during any time, however the story contents get freezes once its is groomed and estimated.

In case of big change in requirement introduced for a story that is already groomed and estimated, The story needs to move back to a state for re-grooming and estimation along with updated requirement.

In case of change in requirement introduced for a story that is already committed for a sprint and the sprint is already started, The Scrum Master needs to manage the situation by checking the size of the change and time left on that sprint, resource  availability, capacity of the team to take additional changes, possibilities of getting approval from Product Owner to dropping any low priority story from current sprint scope. After All delivering business value on time is the primary responsibility of a scrum team.  The Team can mutually decide along with Product Owner’s approval to drop the story from that sprint and plan for next sprint, its all depend upon how urgent the changes needed by the product owner.

Hierarchy of user story

In an Organization structuring and mapping the user story with its parents starting from Strategic investment till task as its child is very important to Plan, Execute and Manage the business development. The below pictorial diagram explain the user story hierarchy and its position.

Here we explained 5 major layers.

  1. Theme or strategic Investment level which is the biggest umbrella or top most layer in the tree, and mostly takes years to complete.
  2. Under Theme it has Initiatives or Epics, which is the second largest item in the hierarchy
  3. and under Epics it has features, which is the immediate parents to a user story, and takes weeks, sometime even months
  4. User stories are child of feature and each story takes couple of days to complete
  5. the bottom most layer placed under user story are the task layer. each user story can have multiple task requirements, and which usually takes few hours to complete

Theme, Epics and features are the portfolio level requirements. Story and Tasks are Sprint level / or execution level requirements.

Please Note that few organizational practices have concept of sub story where they create story under story. We strongly suggest to create features if there is any thing bigger than story and map it accordingly.

Story Hierarchy

Types of user story

User Stories are generally of three types,

  1. User Story
  2. Non User Story
  3. Spike

Details of these three types are explained below

  • User Story

    This is traditionally used through out the Agile life cycle and details of user story and characteristics are explained in details above. user story are deploy-able and holds business value, contain a estimated story point which gets credited to the team upon completion

  • Non- User Story

    This types of user story we create to work on some technical activity to support a upcoming story of business functionality.  we use this story types to create work like, database migration, backup activity, configuring test environment etc. This stories does not contribute any direct value to business, but provide the prerequisites to work on real value addition story.

    Keeping a story points to zero or to some value and contribute to teams velocity is depend upon org level decisions. as this work also needs some efforts from the team member, including this stories during planned capacity mapping is always better approach.

  • Spikes

    User Story of type Spike is also knows and discovery story. which we use to do all our Research and Analysis work, it does not provide any Business value and not deploy-able, how ever as per acceptance criteria a analysis /research outcome document may be deliverable.

Sometimes a Defects or Bug become bigger and required a new development. In those cases we create a user story targeting fixing the issues, with an agreement from Product Owner.

End of Article

Hope this page was able to provide the information you were looking for, In case we missed something, feel free to leave your comments, feedback and suggestions, at bottom of the page’s comment section.

Author(s) of this article

Niladri Mahapatra

1 Comment

  1. اHi dear M.Niladri
    I think you for the help to understand Agile Development LifeCycle and The user story informations which i found it helpfully.
    Sincerely
    RIDHA OMRI
    Stockholm,Sweden

     Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment