Theory "User Stories, Epics, Product Backlog Items"

You have already successfully completed the first chapters, which means that, in theory, you are ready to start your first Scrum project. There are exactly two requirements that must be met: 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 include. 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. User Stories express desires and requirements for the final product, Epics are very extensive User Stories, and Themes are collections of User Stories grouped under a common topic.

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 should be formulated so that they can be further refined and implemented.

User Stories¶

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 added to the Product Backlog. While the technical implementation of the requirements was still added to the Product Backlog when Scrum was introduced, this is no longer included. Technical aspects and matters relating to implementation are added to the Sprint Backlog. This ensures that everyone involved in the project - such as customers, end users, or other stakeholders - can express their needs the Product Owner can do this on behalf of the customer, or they can also formulate User Stories jointly with the Developers.

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 value added. 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 they can also co-create User Stories with the Developers.

When formulating a User Story, the following sentence should be completed with the user's role, the functionality expected of the User Story and the business value contribution:

As ... I would ..., so that ...

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, the User Story must be expressed directly and concisely - 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 via corresponding acceptance tests.

Definition of Ready (DoR)¶

It is important to always have a sufficient number of User Stories in the "ready" status. The Definition of Ready (DoR) indicates that tasks or User Stories listed at the top of the Product Backlog must be described clearly enough for the Developers to understand them 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, a task can only be considered "ready" when the developers confirm they understand it. The PBIs must comply with the DoR and the three Cs; only then are they ready for the Sprint Backlog and can be worked on. They must be sufficiently small and detailed to be broken down 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 Sprint timeline. 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 one of the previous chapters, the primary 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 unnecessary features are implemented 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 is moved from the Product Backlog to the Sprint Backlog, it must first 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 a single iteration, i.e. a 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 based on predefined acceptance criteria.

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 collaboratively writing User Stories and providing them with acceptance criteria. Here, the transition to testable is fluid. A User Story should have approximately three to five acceptance criteria so that, at the end of the Sprint, it can be assessed to determine whether the corresponding Increment functions correctly. A User Story is feasible if it can be implemented within a Sprint, so this criterion is similar to small, which you already know from the INVEST criteria.

Story points and agile estimation¶

Estimating the effort required 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, concrete predictions are avoided, such as how much effort will be required in working hours. Rather, the aim is to determine relative quantities, i.e. the complexity of individual items is estimated relative to one another. The relative effort values make it easier to adapt the release plans to changing conditions that affect 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 decisions are made based on intuition.

The procedure for estimation¶

The estimation workshop is conducted within the team, for example in the form of planning poker. Since the whole team takes part in the estimation workshop and each Developer can contribute their expertise to the estimation and the discussion, such estimations are usually more accurate than others.

• Each entry in the Product Backlog is estimated. Begin with the User Story expected to require the least effort.
• Then all further entries are compared with the first entry and assessed in relation to it.
• The amount of work is usually estimated in story points.

The Fibonacci sequence is recommended for story point estimation: Fibonacci's number sequence is obtained by adding the previous number to the next (1,2,3,5,8,13,21,34). Entries at the higher end of the scale resemble Epics and should be broken down into User Stories in the further course.

Another possibility appart from 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 split up later on.

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 make the final decision regarding the estimation of story points. If it becomes necessary to update the estimations during the Sprint, the Developers are also responsible for updating them.

How Epics become User Stories¶

As you now know, User Stories are transferred from the Product Backlog to the Sprint Backlog to be worked on 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 positioned lower in the Product Backlog. The more User Stories are taken away from the top, the further the other User Stories and Epics move up. Over time, Epics should be refined and broken down so that they become small User Stories and meet the INVEST or CTF criteria as they approach the top of the Product Backlog.