Theory "User Stories, Epics, Product Backlog Items"
You have already successfully completed the first two chapters and can theoretically start your first Scrum project. This is because exactly two things have to be fulfilled: The Scrum Team must be set up and the Product Backlog must exist. As you know from the previous chapter, the Product Backlog is a list of all features that the product should have. The list is created in the form of user stories or Product Backlog items.
Product Backlog Items¶
All entries in the Product Backlog are called Product Backlog Items. These can be Themes, Epics or user stories.
This means that every user story is a Product Backlog Item, but not every Product Backlog Item is a user story. To refresh your memory on the difference between user stories, Epics and Themes:
User stories are wishes and requirements for a final product, Epics are very extensive user stories and Themes are several user stories that are grouped into a common theme.
In this chapter you will learn how user stories need to be formulated so that they can be processed further.
An important factor in the creation and design of the Product Backlog is the customer's or end user's perspective on the product. User stories give the actual user the opportunity to express what they want in their own language. Therefore, the entries are created in the form of user stories and entered into the Product Backlog. While the technical implementation of the requirements was still entered in the Product Backlog when Scrum was introduced, this is now largely dispensed with. Technical aspects and matters relating to implementation are entered in the Sprint Backlog. his ensures that everyone involved in the project - such as customers, end users or other stakeholders - can express their wishes without having technical knowledge or having to express themselves in technical terms.
In a nutshell
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.
A user story is written from the user's point of view and contains information about "role" (who?), "function" (what?) and "business value" (why?), i.e. benefit or added value. However, it is not mandatory that the end user writes the user story. The Product Owner can do this on behalf of the customer or he can also formulate user stories jointly with the Developers.
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 ...
For example, the sentence could be completed as follows:
As an aspiring Scrum Master I would like to be provided with sample exercises so that I can master the certification exam.
Designing user stories - the three Cs¶
Creating user stories involves more than just adding "role", "function" and "business value contribution" to a sentence.
As you can see from the picture above, a user story is written on a card - usually physically, but it is also possible to use digital cards to formulate user stories. Once the user story has been formulated, you and your team should discuss about it - this happens at the latest when the effort is estimated. And finally, it is important to note that a user story must be accepted at the end of a Sprint - this is done on the basis of previously defined acceptance criteria.
So you have to keep the three Cs - card, conversation and confirmation - in mind when creating 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.
Definition of Ready (DoR)¶
It is important to always have a sufficient number of user stories in the "Ready" state. 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. As you have read above, it is crucial that the Product Owner and the Developer discuss user stories and that user stories are understood before they are implemented.
In other words, only when the Developers say they understand an upcoming task it can be considered "ready". The PBIs must comply with the DoR and the three Cs, only then they are ready for the Sprint Backlog and can be processed. They must be sufficiently small and detailed to be converted into tasks. This means that they can be transferred to Sprint Planning at any time and subsequently added to the Sprint.
If Product Backlog Items do not correspond to the DoR and the Developers have not understood them properly, the development effort can increase and the processing of the PBIs can exceed the schedule of the Sprint. In the worst case, this leads to the Sprint Goal being missed or an Increment not being delivered on time.
There are various criteria that can be used to check whether your user stories meet the Definition of Ready:
The INVEST criteria¶
To make a user story feasible, it should be independent, so that it can be worked on and prioritised individually and not in connection with other user stories. The advantage of this is that it does not affect other user stories when you are working on it.
While user stories should be detailed enough for Developers and other stakeholders to have an idea of what is involved, there should still be enough room for discussion. If the discussions lead to adjustments, the user story should be negotiable.
As you already know from the previous chapter, the highest goal of the Developers is to create a valuable increment in each Sprint. And to achieve this, it is necessary that the user stories are valuable, so that no features are implemented that are ultimately unnecessary and do not bring the Developers closer to their goal.
Furthermore, a user story must be estimable. This is important in order to transfer a user story from the Product Backlog to the Sprint Backlog - because before a user story "moves" from the Product Backlog to the Sprint Backlog, it must be estimated by the Developers.
The size of a user story also plays a role. It should be small enough that it can be implemented within one iteration, i.e. within one Sprint.
It is also important that the Developers can test the implemented user story at the end of a Sprint. The user story must therefore be testable. Testing is done on the basis of previously defined acceptance criteria.
INVEST - The acronym as a mnemonic
An acronym that helps you to better remember the criteria that a user story should meet is "INVEST":
The CTF criteria¶
The CTF criteria are similar to the INVEST criteria. A user story must be clear, testable and feasible.
"Clarity" is achieved by co-authoring user stories and providing them with acceptance criteria. Here the transition to "testable" is fluid. A user story should have about three to five acceptance criteria so that at the end of the Sprint it can be assessed whether the corresponding increment works. A user story is "feasible" if it can be implemented within a Sprint, so this point is quite similar to "small", which you already know from the INVEST criteria.
Even if a user story meets the INVEST or CTF criteria, this is no guarantee that the user story will be successfully implemented in the next Sprint. If the user story does not meet the Definition of Ready (DoR) and the Developers only realise during the process that they do not understand the user stories, this can have a negative impact on the implementation. Accordingly, implementation should only be carried out when the Developers have explicitly stated that they have understood what the user story is about.
Story points and agile estimation¶
Estimating the work effort necessary to implement user stories in the Product Backlog is a crucial aspect of agile project planning. It gives the Scrum Team an idea of the total scope of work over the course of the project.
In doing so, you refrain from making concrete predictions, such as how high the effort could be in 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").
The procedure for the estimation¶
The estimation workshop takes place in the team, for example in the form of a "planning poker". Since the whole team takes part in the estimation workshop and every Developer can contribute their experience to the estimation and the discussion, such estimations are usually more accurate than others.
- Each entry in the Product Backlog is estimated. Start with the user story that is expected to require the least amount of work.
- Then all further entries are compared with the first entry and evaluated relatively to it.
- The amount of work is usually estimated in story points.
What are story points
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.
The Fibonacchi sequence is recommended for story point estimation: Fibonacci's number sequence is obtained by adding the preceding number to the following number (1,2,3,5,8,13,21,34). Entries at the upper end of the scale already have the character of epics and must be divided into user stories in the further course.
Another possibility besides the story points is to compare the entries with dress sizes. These are: XXS, XS, S, M, L, XL and XXL. Entries at the lower end of the scale already have the character of epics and must be shared in the further course.
The story points are discussed in the team. The Developers go through all the entries of the Product Backlog together with the Product Owner and any open questions are clarified. The Developers then make an estimate. The Developers have the final say in the estimation of story points. If it becomes necessary to update the estimations during the Sprint, the Developers are also responsible for this.
How Epics become user stories¶
As you now know, user stories are transferred from the Product Backlog to the Sprint Backlog to be processed there. They have to be small and feasible enough to be implemented within one Sprint. Since the Product Backlog is processed from the top and Epics are too large and too complex to be implemented within a Sprint, they are placed further down in the Product Backlog. The more user stories are taken away from the top, the further the other user stories and Epics "slide" up. In due course, Epics should be further formulated and split up so that they become small user stories and meet the INVEST or CTF criteria once they reach the top of the Product Backlog.