Table Of Content
Hierarchy of User Story
As we all know that, user story plays pivotal role in delivering users requirements and thus meeting Sprint’s goal.
Before looking into the elements of user story, let us look at the hierarchy of user story.
Every user story should be linked to Feature and every feature should be link to EPIC in Agile-Scrum mode of execution.
- EPIC-Epics are large quantities of related work that can be broken down into features.
- Feature-A feature is something that is sizeable enough to deliver measurable value to customers and creates a large chunk of functionality. Features are used to describe the functionality at a macro level, and they are required to create schedules and plan the high-level release of the product. A feature is the product’s service/function that provides business value and meets customer needs. Each feature is then divided into several user stories as it is too hard working on large chunks directly.
- User Story– A user story in Agile software development is a mechanism used to capture user’s requirement describing the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
Structure of User Story
As a — this is the WHO. Who are we building this for? Who is the user?
I want — this is WHAT. What are we building? What is the intention?
So that — this is WHY. Why are we building it? What is the value for the customer?
Examples of User Story
- As an online banking user, I want to see a rolling balance of my all accounts, So that I can keep track of all my income and expenses on daily basis
- As a customer, I want to receive SMS when the item is arrived so that I can go pick it up right away
Elements of User Story
Every user story should have following elements to make it comprehensive and informative and deliverable/shippable –
- Description – As stated above, user story should describe requirement from user’s view point and that is captured under “Description” field
- Acceptance Criteria – Every user story should have acceptance criteria defined in format of checklist or “Given, when & then” format. User acceptance criteria in given/when/then format follows the template: “Scenario: (explain scenario). Given (how things begin), when (action taken), then (outcome of taking action).” Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended.
- Example of Acceptance Criteria –
Given (What we have on hand) – Given that we have CRM archived files for purging When (What will you do) – Establish logic of removal of files Then (Objective/Goal) – Removal of files which are 7 or more days old
- DOD – Definition of Done – DoD is a shared understanding within the Scrum Team on what it takes to make your Product/Functionality Increment releasable. The Definition of Done is an agreed-upon set of items that must be completed before a user story can be considered complete. It is applied consistently and serves as an official gate separating things from being “in progress” to “done.” In specific terms, the Scrum definition of done is a list of conditions that must be met to successfully mark a product increment as complete.
- Example of DOD –
In software, a Definition of Done may be: “Done means coded to standards, reviewed, implemented with unit Test-Driven Development, tested with 100 percent test automation, integrated and documented.”
Another example of DOD – Development done, code review done, Unit testing completed & Meeting the acceptance criteria
- Story Points – In Scrum, Backlog items are commonly translated into user stories and estimated with story points. Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. Story points are an estimation technique used in agile project management methodologies to help your team scope the effort required to complete a task. Story points account for factors like task complexity and uncertainty, which makes them more accurate than other estimation techniques such as time-based estimation. Basically there are two types of estimation –
- Solid/Concrete – Specific or Solid or Tangible and measured in hours, days, man-months/person-months and another type is
- Abstract – measured with subjective using techniques like T-Shirt sizing, Poker Planning, Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.)
- Sprint Backlog Tasks (SBT) – Each user story point is further divided into single sub-task or multiple tasks but it should have at least one task and the task need to be estimated in hours. At end of each day, the assigned task to scrum team need to be burned in terms of hours burned/used in order to complete the task/s
Summary
As stated, user story is the most important aspect of Scrum execution methodology enabling to deliver user’s requirements captured and elicited end-to-end.
Some of the benefits of user story –
- Highest Value Delivery
- Encourages Collaboration among interested stakeholders like Product owner, product development team and product users/consumers
- Brings User Closer
- Enables to build Product incrementally
- Encourages Transparency – Transparency reduces a lot of waste from the process and improves team’s effectiveness
Thus user story enables to deliver value for money or money invested
FAQs
Q1. What are the essential elements of a user story?
A1. The essential elements of a user story include a clear and concise description of a feature or functionality, the user or customer who benefits from it, and the reason or goal behind the feature. Additionally, acceptance criteria that define when the user story is complete are crucial.
Q2. What is the purpose of a user story in software development?
A2. The purpose of a user story in software development is to capture user requirements and expectations in a simple, understandable format. It helps teams focus on delivering value to users by describing what needs to be built from the user’s perspective.
Q3. How should acceptance criteria be formulated in a user story?
A3. Acceptance criteria in a user story should be specific, measurable, achievable, relevant, and time-bound (SMART). They should clearly define the conditions that must be met for the user story to be considered complete and satisfy the user’s needs.
Q4. What is the difference between an epic and a user story?
A4. An epic is a large, high-level user story that represents a broad user need or feature. User stories, on the other hand, are smaller, more detailed pieces of functionality that are derived from epics and provide actionable requirements for development.
Q5. How can user stories help improve communication within a development team
A5. User stories improve communication within a development team by providing a common language for discussing and understanding user requirements. They promote collaboration and ensure that everyone on the team has a shared understanding of what needs to be built and why.
Author
