Theory "Sprint Backlog"

The Sprint Goal: The link between Sprint Planning Meeting and Sprint Backlog?¶

In the previous chapter, you learned that the Sprint Goal must be set before the Sprint Planning Meeting is finished. However, the Sprint Goal runs like a thread from the Sprint Planning Meeting through the entire Sprint - because the Sprint Goal is literally the only goal of the Sprint. Although user stories are processed during the Sprint, they are only executed with the aim of achieving the Sprint Goal and thus successfully completing the Sprint. The Sprint Goal plays a central role not only during the Sprint Planning Meeting and during Sprinting - the Sprint Goal is also essential for the Sprint Backlog. This is because the Sprint Goal is the Commitment that belongs to the Artefact "Sprint Backlog".

The Sprint Goal as a commitment should encourage the Scrum Team to work together and it creates a common vision. After it has been developed, it is included in the Sprint Backlog and serves as a target for the Developers, towards which they can work in a focused manner, true to the motto: You can hit a target that you can see better than one that you can't see. But the Sprint Goal is not only important for the Developers, stakeholders also have a legitimate interest in the Sprint Goal, because it reflects why a Sprint is valuable for them and they can see the added value of the Sprint at a glance.

Your formulated Sprint Goal should always answer this question: Why is this Sprint being carried out?.

Examples of Sprint Goals are:

• Integrate search function on website: Why does this make sense? This is the only way potential customers can search the website.
• Enable payment via PayPal: Why does this make sense? Customers can pay easily this way and the company can earn money with it.
• Develop a web-learning concept: Why does this make sense? Based on the concept, the content can be created.

Problems with Sprint Goals¶

When formulating the Sprint Goal, answer the question why you are carrying out the Sprint in the first place and why it is worth doing. User stories or PBIs are not a Sprint Goal! A Sprint Goals should be broader, but still set the direction. However, if a Sprint Goal is formulated as too broad, problems arise: The Developers might not be able to achieve the Sprint Goal, which can lead to the Sprint being cancelled. However, if the Sprint Goal is described too vaguely, the Developers may lose sight of it and cannot work towards it. It is also problematic if the Developers do not have the meaning of the Sprint Goal in mind and motivation decreases as a result.

It is therefore important to formulate the Sprint Goal properly - you could use the SMART-critiria.

The solution: The Sprint Goal should be SMART¶

You probably already know it from your previous projects or other tasks: Goals have to be SMART - and so it is with the Sprint Goal. It should be specific, measurable, achievable, reasonable and time-bound.

Specific¶

What should be achieved?

Measurable¶

How will you measure whether the goal has been achieved? Determine in advance how you plan to measure the Sprint Goal.

Achievable¶

The Sprint Goal should neither under- nor overwhelm. It must be achievable.

Reasonable¶

The implementation should be relevant for the customer/stakeholder, but also reasonable from the Developer's point of view.

Time-bound¶

A Sprint is always time-bound, i.e. the end is predetermined.

What happens after the Sprint Planning Meeting?¶

By the end of the Sprint Planning Meeting, the Sprint Goal is known to all participants and the selected user stories that need to be implemented in order to achieve this Sprint Goal are estimated and divided into tasks. The tasks have been transferred to the Sprint Backlog - e.g. in the form of a Scrum task board. This is updated daily so that it can be discussed during the Daily Scrum Meeting. The acute updates and, if necessary, changes are carried out by the Developers. The Sprint Backlog should be put in a visible place - in the office or virtually. This makes it possible to always see where the Sprint is, which user stories are currently being worked on and which tasks still need to be completed. This gives the Developers an overview of the entire Sprint.

The Sprint Backlog - is the list of Product Backlog Items to be processed in the current Sprint, - consists of entries that are taken from the Product Backlog, - is the description of the technical measures (tasks) for implementation and realisation (e.g. design, architecture, programming, testing and refactoring), - is the responsibility of the Developers, as they make a prediction of the functionalities to be developed, - is placed in the office for all to see. Maintenance and updating is done timely to the Daily Scrum Meeting, - serves to visualise the progress.

Structure of the Sprint Backlog¶

The Sprint Backlog is divided into four columns. On the far left, all user stories that were selected in the previous Sprint Planning Meeting are listed. At the top is the user story with the highest priority. The lower the user stories are listed in the Sprint Backlog, the lower their priority - similar to the Product Backlog. To the right in the To-Do column you can find the tasks that are necessary for the implementation of the respective user story into an increment. The tasks are arranged as determined by the Developers in the Sprint Planning Meeting. The next column shows what is currently being done. The abbreviation "WIP" is often used for this, which stands for Work in Progress. The rightmost column lists the work that has been completed. The column is therefore called "Done". This makes it easy to visualise what is being worked on at any time. If the Developers are distributed across different locations, you should think about using a software-based Sprint Backlog.

Why is a Sprint Backlog useful?¶

By using a Sprint Backlog, the Developers can directly see where the Sprint is at the moment, and, based on this, they can also use the Sprint Backlog to answer the questions which are asked during the Daily Scrum Meeting. Through the visualisation, the Developers also recognize when tasks have been in the "Work in Progress" column for too long. If tasks are in this column for an unusually long time, the Developers should ask themselves why this is the case. Has the task been misjudged? Are there problems? If the first is the case, then the Developers can use this information to improve their estimation skills in subsequent Sprints. If there are problems, they must be discussed during the Daily Scrum Meeting in order to remove these impediments and to support the Developer(s). Another advantage of a well implemented Sprint Backlog is that scope creep is prevented.