Exercises "User Stories, Epics, Product Backlog Items"
Here you will find the definitions of the most important terms from this chapter.
- Card - physical or digital
- Conversation - Product Owner and Developers have exchanged ideas about the user story
- Confirmation - Acceptance criteria have been recorded.
Relative estimation of the workload related to the entries in the Product Backlog based on story points or similar, usually in a team.
Definition of Ready¶
A term for entries in the Product Backlog that have been understood by the Developers and are ready for the implementation in the next Sprint. Usually, these are top-listed entries that must meet the Definition of Ready.
The perceived workload and value of a user story. Story points can be affected by uncertainties, for example, or by the quantity and complexity of the work. They are neither monetary nor time-based, but are themselves the unit of measurement for estimating the Product Backlog Items.
Planning Poker, also known as Scrum Poker, helps Developers to estimate the relative effort or complexity of individual Product Backlog Items. For this purpose, the Developers come together in the team and use a kind of card game. Numbers, clothing sizes, etc. are written on the cards, which are used for the estimation.
Answer the following questions independently. Please take your time and think carefully about what you would answer before revealing the solution.
What are the contents of user stories?
A user story contains information about "role" (who?), "function" (what?) and "business value" (why?). When formulating a user story, the following sentence should be completed with the role the user plays, the functionality expected from the user story and the business value contribution:
As ... I want ..., so that ...
What does Definition of Ready mean?
The "Definition of Ready" (DoR) indicates that tasks or user stories listed at the top of the Product Backlog must be described in such a way that they are understood by the Developers and can be implemented in the next Sprint.
Why are user stories written at all? What do you have to pay attention to when writing them?
User stories help Developers to understand what end users want and end users can easily communicate their wishes without having to have technical know-how. In this way, a common understanding is created. When writing, the three Cs should be followed and user stories should meet the INVEST or CTF criteria.
Who writes user stories?
User stories are formulated from the user's point of view. They can be written by the user himself, by the Product Owner or jointly by the Product Owner and the Developers.
What does the acronym INVEST stand for?
In what context do INVEST or CTF criteria apply?
INVEST or CTF criteria are important when it comes to the Definition of Ready. User stories that are at the top of the Product Backlog must be "ready" for the Developers to start working on them. This means that the Developers must confirm that they have understood the user stories and that the user stories meet the INVEST or CTF criteria so that they can be implemented in the upcoming Sprint.
Please explain the three Cs of user stories.
Card: The most important details of a user story are recorded on a card. This includes the priority of the user story, its acceptance criteria and also the amount of work required to implement a user story, which was determined via estimation. Since a card only offers limited space, the user story must be expressed straight to the point.
Conversation: A short and concise user story should lead to a discussion between the Product Owner and the Developers. They should discuss the user story in detail and everyone should understand the goal of the user story.
Confirmation: Acceptance criteria must result from the discussion between the Product Owner and the Developers, and these criteria must be documented. The Product Owner accepts the implementation of the user story as an increment through corresponding acceptance tests.
What is a story point?
Story points represent the perceived workload and reflect the value of a user story. Story points can be affected, for example, by uncertainties, by the amount and complexity of the work. They are neither monetary nor time-based, but are themselves the unit of measurement for estimating the Product Backlog Items.
What is dispensed with in agile estimation and why?
Concrete predictions are not made (e.g. working hours). Rather, the aim is to determine relative quantities, i.e. the complexity of the individual entries is estimated in relation to each other. The relative effort quantities make it easier to adapt the release plans to changed boundary conditions that alter the velocity (development speed) and to assess the effects of the changes. The focus is placed on intentional imprecision, rather than exact numbers, and thus on non-linear number scales. In addition, the decision is made according to instinct ("gut feeling").
What are the different ways of estimating?
Common methods of estimation are the Fibonacci sequence or dress sizes.