🪄User Story
User Stories
A user story is a short description of a feature or functionality told from the perspective of the user. It captures what a user needs to do and why.
Writing User Stories
Some guidelines for writing good user stories:
Start with:
"As a [user role], I want [goal/desire] so that [benefit]."
Write in simple, non-technical language focused on the user need
Limit to small, distinct pieces of functionality that can be built in one sprint
Use themes and personas to frame the user perspective
Include just enough detail for developers to understand the scope
Acceptance Criteria
Acceptance criteria defines the boundaries of a user story and what must be done for it to be accepted:
Specified in bullet point form under the story
Acts as input for test cases
Includes functional, non-functional, and UX requirements
Focuses on business and user value vs. technical details
Grooming User Stories
The backlog is groomed through discussion of user stories:
Assess clarity, dependencies, risk, assumptions
Split or merge stories as needed
Estimate effort by agreeing on story points
Prioritize stories based on business value
This process ensures stories are ready for the team to execute in a sprint.
User Story Lifecycle
User stories move through states of writing, grooming, sprint planning, implementation, testing, and completion based on acceptance criteria.
User Stories in Agile
User Stories, as their name suggests, center around the requirements and experience of users. As a result, they incorporate the first principle of the Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
What makes a good User Story?
User Stories evolve over time from vague, nebulous concepts into specific, well-articulated needs. A good way to assess whether a User Story is well defined is to use Bill Wake's INVEST mnemonic.
The INVEST mnemonic encourages teams to ask the right questions of their User Stories or Product Backlog Items (PBIs).
Your User Stories, as the table below shows, should be: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
INVEST
Independent
Independent of other User Stories, meaning they can be developed in any order
Negotiable
Facilitate open conversation within the development team: changes to the User Story can be discussed and implemented
Valuable
Bring value to user/stakeholder, adding overall value to the product
Estimable
Able to be estimated using the sizing criteria discussed, e.g., T-Shirt sizing or Story Points, allowing prioritization and scheduling
Small
Must be manageable enough to be developed in a single iteration, and not so detailed that ongoing conversation is redundant
Testable
Should only be considered done once it meets agreed acceptance criteria that can be tested and validated
If your User Stories meet the INVEST criteria, then your team is set for success in its workflow management.
User Story Benefits
User Stories offer a great number of benefits to development teams:
Stories ensure the team remains focused on the benefits for the user and the business value, ultimately developing a better product that is not only well built technically, but also brings real value to real users.
User Stories encourage and facilitate collaboration. With the focus on a team-wide discussion rather than on lengthy, written explanations of requirements, the team is freed up to collaborate, drawing on one another’s strengths and expertise.
User Stories foster creativity. The team are encouraged to critically and creatively consider how to achieve the end goal.
Stories create momentum. The development team complete small, manageable tasks consistently as the User Stories pass through the workflow, offering a regular sense of achievement and creating pace.
What are Story Points? 💡
Story Points are a relative measure of the effort and complexity required to implement a user story. They are used to estimate how much work can be completed in a sprint.
Why Use Story Points Instead of Hours? ⏱️
Using abstract points instead of hours helps account for the uncertainty in estimating and the varying capacities of team members.
How are Story Points Assigned? 📏
During sprint planning, the team plays Planning Poker 🃏 to estimate the size of each story using the Fibonacci sequence:
1, 2, 3, 5, 8, 13, 20, 40, 100
The discussion and negotiation lead to consensus on the story point value.
What Do Story Points Represent? 🤔
Story points represent the overall effort required to complete a user story. This includes:
Design
Development
Testing
Documentation
The focus is on the total effort, not just development time.
How Are Story Points Measured? 📈
Story points have no specific numeric value. They are relative units of measure:
A 5-point story requires five times as much effort as a 1-point story.
A 20-point story requires twice the effort of a 10-point story.
What is Velocity? 🚀
Velocity represents the number of story points the team completes within a sprint.
Velocity = Total Story Points per Sprint
Velocity helps the team forecast how much work they can complete in upcoming sprints.
Key Takeaways 📝
Story points are abstract, relative units of measure for estimating effort.
They account for uncertainty and varying team capacities.
Velocity represents the number of story points per sprint and helps with forecasting.
Last updated