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
- A developer can start and finish his development
- A tester and test the developed code to check if it is meeting the required functionality
- 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
- Role
- Goal
- Benefit
- 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
- I 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]
- 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
- 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. - 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 - 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 - 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 - 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.
- Theme or strategic Investment level which is the biggest umbrella or topmost layer in the tree mostly takes years to complete.
- 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
- User stories are a child of features and each story takes a couple of days to complete
- 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,
- User Story
- Non-User Story
- 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
For more posts like this follow Agile Digest social Pages or subscribe our newsletter:
Wesbite: https://agiledigest.com/
Facebook: https://www.facebook.com/agiledigest/
LinkedIn : https://www.linkedin.com/company/agiledigest/
Youtube: https://www.youtube.com/@AgileDigest
