Understanding User Story

What is a user story?

In Agile Software development, the execution level requirement or functionality is termed a 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. The product owner/ BA / Stakeholder can verify the desired functionality to accept the story completion. Each story has been to fulfill a requirement with a very specific goal or benefit, it’s always advisable to break any store into smaller stories if it has more than one goal. The requirement of a story has to be of complete functionality, which means that upon completion of development, testing, and acceptance, the code should be deployable or parked for future release. In another word, each user story should be potentially shippable. The size of a user story is measured in story points (Refer to 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 are very crucial for a user story to use in unit testing, QA, and story acceptance by the product owner or Stakeholders.

Understanding the 3Cs.

A well-structured user story should have three sections

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

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

3. Confirmation.  This is the area 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 the heading “Acceptance Criteria” A typical template of a user story is like an <Role> I want <Goal> so that <Benefit / Expected outcome>. The Acceptance criteria are very crucial for a user story to use in unit testing, QA, and story acceptance by the product owner or Stakeholders. 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

  • independent
  • N negotiable
  • V valuable
  • E estimable
  • Small
  • T estable

Refer to the below diagram to read more about each characteristic.

Example of a good user story

Example 1

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

Acceptance Criteria [Abstract]

Products can be added to the cart

Products can be removed from the cart.

The shopping cart will be empty initially

The shopping cart will be empty after the purchase

Products can be added with multiple quantities in the cart

The shopping cart will show the total product breakdown quantity

Example 2

As an online visitor, I want to add products to my shopping cart so that I can purchase multiple products in 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 quantities of the product, and I can see a warning that the product has more than one quantity.
  2. Given my Shopping cart contain 1 or more product
    When I click on the delete button inside the 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, carts contain one or more product
    When click on confirm the order on the cart page
    Then My shopping cart should go empty after successful order
  4. Given shopping carts contain one or more products
    When Open Cart page

    Then It Should show all the products broken down with their selected quantity and cost and appropriate totals of cost and quantity
  5. Given shopping cart contain one or more products on the Cart page
    When changing the quantity of any product  Then the product’s cost should be updated and subtotals of quantity and cost should change accordingly
Attachments:

The wireframe of the Cart page is attached.

End of Section Structure of a User Story

Associations of a user story

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

One to One relation with user story and associated information

Story ID

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

Story Title

A 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 an example in the above section could be “Adding product to cart”

Story Rank

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

Story Description

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

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 of the story point in the Estimation and planning section. The possible values should be 1,2,3,5,8,13,21,… in the Fibonacci series, This is also called relative sizing.

Story State

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

The Good example of workflows for the stages of User stories is also available below which breaks down the stages into smaller and better trackable units

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 gets blocked during its in-progress stage

Blocked Reason

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

  • A cross-functional team has not completed their user story marked as our story’s Predecessor
  • The task assigned to UX has not yet started working, delaying dev work
  • Test data is not available to do a unit testing

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 stories by making another user story as a parent, which we advise avoiding if possible. Will learn more about the User story and its hierarchy, later on, on this page.

Release Information

This information contains the release number it is planned for, It’s optional information that can be added at any stage of its life cycle.

Sprint Information

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

Owner

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

Assigned to

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

Project Code

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

One to Many relations with user story and associated information (Optional)

Child Story

Few organizations or practices create sub-stories or child stories under one user story, we personally advise map stories with features as parents for better mapping and tracking.

Task(s)

Tasks are the bottom-most layer in the user story hierarchy and are always children of a 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. Examples of tasks redevelopment, Database Design, UI Design, Testing, ….Remember the effort estimation on tasks are man-hours, it has no direct relation with story points

The successor (s)

Successors are the dependent story linked to your story. The successor story can only start its development once your story is complete. for example your story: Import Test data for Online purchase functionalitySuccessor story: Online Purchase functionality enables adding products to the cart

Predecessor(s)

Predecessors are just the opposite of successors, This is also part of story dependency. You can only start working on your story once the predecessor story is completed. for example your story: Online Purchase functionality enables adding the product to the cartSuccessor story: Import Test data for Online purchase functionality

Discussion(s)

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

Test Case(s)

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

Attachment(s)

Product Owner or Stakeholders or BA or anyone can provide attachments to enhance the requirement, also testers can attach test results as proof of testing passed or fail status.

Tag(s)

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

Who can write or update user stories?

The Product Owner is primarily responsible for the contents of a user story. In some places, the Business Analyst also gets involved to write and take responsibility for user story content. Team members can help the product owners or BA to write user stories, but as a product owner or BA understands the business requirements and acceptance criteria better than any other team member it’s always a good idea to leave this responsibility with the product owner or Business Analyst. Once the Initial Draft is created, the Product Owner or BA can enhance the requirement from the input from Team members or external resources, captured during GroomingHowever, there are instances of creating Spikes (I will discuss spikes later on this page), Developers, Testers, UX team members, etc can write those special types of user stories

When user story can be written or updated

User Story can be written at any time, however, the story contents get frozen once it is groomed and estimated. In case of a 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 requirements. 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, the capacity of the team to make 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 the Product Owner’s approval to drop the story from that sprint and plan for the next sprint, it all depends upon how urgent the changes are 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 to task as its child is very important to Plan, Execute and Manage the business development. The below pictorial diagram explains 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 topmost layer in the tree mostly takes years to complete.
  2. Under Theme, it has Initiatives or Epics, which is the second-largest item in the hierarchy, and under Epics, it has features, which as the immediate parents to a user story, and takes weeks, sometimes even months
  3. User stories are a child of features and each story takes a couple of days to complete
  4. the bottom-most layer placed under the user story is the task layer. each user story can have multiple task requirements, and which usually takes a few hours to complete

The 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 a concept of sub-story where they create a story understory. We strongly suggest creating features if there is anything bigger than the story and mapping it accordingly.

Types of a 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 throughout the Agile life cycle and details of the user story and characteristics are explained in detail above. a user story is deploy-able and holds business value, contains an estimated story point which gets credited to the team upon completion

Non-User Story

This type of user story we create to work on some technical activity to support an upcoming story of business functionality.  we use these story types to create work like, database migration, backup activity, configuring test environment, etc. This story does not contribute any direct value to the business but provides the prerequisites to work on a real value addition story. Keeping a story points to zero or to some value and contributes to team velocity depending upon org-level decisions. as this work also needs some effort from the team member, including these stories during planned capacity mapping is always the better approach.

Spikes

User Story of type Spike is also known as and discovery story. which we use to do all our Research and Analysis work, it does not provide any Business value and is not deployable, however as per acceptance criteria the analysis /research outcome document may be deliverable.

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

End of Article

Niladri Mahapatra

Niladri Mahapatra

Leave a Replay

Sign up for our Newsletter

Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit

Shopping Cart
Scroll to Top

EARN FROM YOUR SPECIALIZED SKILLS

We may not be experts on everything, but all of us have some skills that we are super experts in, It can be Agile, It can be Excel or Jira or Java or Database or Machine Learning or Project Management or UI Design, or anything else.
Sounds Interesting? wants to know more? feel this form we will contact you and explain the next step and process. Does not matter which country you belong to and which Time zone you are in we all have potential needs everywhere. 
You may be Trainer, Freelancer, Full Time Employee, or consultant. Why not you earn little extra money with your expertise on your available time. You chose what you want to do, support another professional or train a group of people or participate in a small or large project choose the skill you complete hold. On top of that, you choose the rate that you want to charge. Get yourself exposed to the people who may need your service.

Offers and Discounts

On Going

SAFe

Attractive Discounts and Offers on SAFe Certification

On Going

Special Discounts on Excel Template, 


Connect with our Chat Agents for more information and to grab more offers and discounts

Next 4 Weeks Training and Events at a glance