User story, User story template, Story points estimation, Planning poker game, User story format, INVEST principle
User Story is a short description of a small piece of desired functionality that is written in a way that tells a story from the user’s perspective and is a small increment of value that cam be developed in several days. It is also a brief statement of a functional product need from the perspective of a specific type of user. A user story follows the template of having a title, a main character/stakeholder, what the user wants and why, additional details and the acceptance criteria. A story is short and simple, containing just the minimum information required in order to be estimated and prioritized.
User Story template
- As a user role: user type or user group type, defined different roles are having different market value
- I want/need some feature: active voice of the user, not technical, achieve a defined goal
- So that some reason/benefit: why is this valuable for the customer, understand what to accomplish and how to prioritize
The notes, comments, questions and constraints resulted from communication are increasing its details during the lifecycle of the user story. Agile teams use scenarios to understand the story, put the information into context, abstract it, then write it in the user story format.
Acceptance criteria provide the details of the User Story from a testing point of view and can be written in a Given-When-Then format.
Personas are user roles described as detailed fictional characters which are acting as a representative user or group of users and use the product in slightly different ways.
Epic is a large placeholder of functionality that does not fit in a sprint and is broken down into stories that have a common objective.
FEEDBACK splitting technique for epics into user stories: Flow, Effort, Entry, Data operations, Business rules, Alternatives, Complexity and Knowledge.
Theme is a very large placeholder that combines related epics that have something in common and belong to the same functional area.
Code spikes are time boxed prototypes for insufficiently mastered technology, designed to increase technical understanding for estimating another user story, to reduce the risk, understand a functional need, increase the reliability of the estimation or to define a technical approach.
Technical stories are development or maintenance work for internal reasons, less visible to the end user.
3 Cs format
- Card – a visual written short description of the story used for planning and estimation
- Conversation – discuss your ideas with others, let them ask lots of questions, work together to come up with ideal solutions and build a shared understanding
- Confirmation – the acceptance criteria of the user story, the agreement on what to build written as a set of confirmation tests
INVEST principle for a User Story
- independent – provides value to the user by itself and can be developed separately
- negotiable – it is not a detailed specification and the methods for achieving the goal can be negotiated
- valuable – written in a way that is valuable to the customer and provides a benefit for the end user
- estimable – it has the right amount of information to be estimated, planned and committed to
- small – a piece of functionality that can be completed in a sprint or in several days
- testable – contains clear and precise ways to verify completion and acceptance
Story points estimation
A story point is a relative and abstract unit of measurement for effort required to complete a user story and it is the combined result of the expected volume of effort required to complete a user story, the perceived complexity of the user story, the knowledge the team has for the described work and the uncertainty in requirements and development needed.
Story points estimates are educated guesses and not a guarantee, nor a deadline, because perfect story points estimates do not exist and pursuing that does more harm than good. When estimating new items, a few voting and discussion sessions take place until alignment is reached, otherwise, the specific item might be split or documented more for another refinement session. Teams agree what type of estimate they will use: most likely, median, risk averse or worst case and they try to get estimates right on average for many user stories, not for each individual user story estimated.
Individuals find it hard to estimate outside of their discipline, to estimate to the same level of completeness as a team, they might make relative comparisons against old or badly estimated items and to get new people accustomed to the baseline used by the team when estimating. Also, estimating too much in one session can lead to burnout. In order to avoid this, it is better to use affinity estimating for some user stories, instead of planning poker.
Planning Poker/Scrum Poker agile estimation game
Planning Poker is a consensus-based gamified technique for estimating as a team the relative size of a user stories in story points. Each team member gets a deck of cards with numbers that represent a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100), they read the user story and estimate privately, then they reveal simultaneously the number card, they discuss reasons for the differences in high and low story points estimates and take additional rounds of estimation and debate until consensus is reached and the final story points for the user story are agreed by the entire team.