What is a Sprint Planning?

The prerequisite for Sprint Planning is a maintained and prioritised Product Backlog. It serves as a source for creating a selection of the most important and highest prioritised backlog items. The selection is often referred to as Selected Backlogs.¹ The Selected Backlog is a kind of wish list of the Product Owner. How many and which backlog items are included in the Sprint Backlog and which ones are actually implemented is decided jointly by the developers.

Participants in Sprint Planning

The Scrum Team – i.e. all developers, the Scrum Master and the Product Owner – takes part in the Sprint Planning. The meeting is organised by the Product Owner, moderated by the Scrum Master, who is responsible for adhering to the agreed process and for communication between the participants.

Stakeholders such as users, partners, representatives from sales or marketing can be invited to the Sprint Planning, but they should rather be somewhat passive and see themselves as advisors. Ideally, the Product Owner has already discussed the content and meaning of the requirements with the stakeholders and developers before the meeting.

Sprint Planning as Scrum Event

Scrum is a communicative process with different events that are carried out within a Sprint. These include Sprint Planning, Daily Scrum, Sprint Review and Retrospective. The Backlog Refinement is also carried out regularly, even if it is not considered an event according to the Scrum Guide.

The number of events shows that communication, dealing with the development, working on jointly agreed goals are very important. No event is more important than another, because each event has its own goals and therefore a concrete purpose.

Sprint Planning 1 in practice

In practice, Sprint Planning is usually divided into two phases or parts: Sprint Planning 1 and 2. Sprint Planning 1 deals with the “Why” and the “What” – i.e. “why” the Sprint has value and “what” should be done in the Sprint. It consists of the following steps:

• The Product Owner suggests how the product to be developed could increase its value and utility in the current Sprint. Some publications also talk about the vision of the Sprint. The vision gives the developers an overall view and a better understanding of what the next Sprint will be about. Even if the Scrum Guide does not explicitly call for this step, practice shows that the orientation towards the vision helps the team to define and later achieve the Sprint Goal. The longer a sprint takes, the more important this orientation becomes. From the vision emerges the Sprint Goal and the Sprint Goal is a step on the way to the Product Goal.
• Naming of the items – as a Selected Backlog – by the Product Owner and subsequent discussion with developers with the aim of recognising professional and technical backgrounds as well as correlations and gaining an idea of the feasibility of the content.
• Refinement of the Acceptance Criteria of the items – which can be available as User Stories, for example. If necessary, concrete acceptance tests are already formulated.
• Estimation of the effort required for the realisation of the items by the developers, e.g. in story points, person days or T-shirt sizes.²
• Transfer of the discussed items into the Sprint Backlog, taking into account the maximum number of tasks to be realised. If the Sprint Backlog is “full” the estimation of other requirements can be postponed to the next Sprint Planning.
• Commitment (i.e. the obligation) of the developers to achieve the sprint goal together and to realise the discussed items during the sprint.

Phase 1 of Sprint Planning ends with the commitment of the team.

Sprint Planning 2 in practice

With the commitment of the developers, the task of the Product Owner in Sprint Planning is complete. In part 2 of the meeting, the developers discuss the technical details of the Sprint Backlog Items or User Stories to be realised, usually without the Product Owner, who should be available for further questions, and without the possibly present stakeholders. Sprint Planning 2 deals with the “how”, i.e. the question of “how” the agreed requirements are to be implemented. The following steps are carried out:

• Structuring of the items into work packages – i.e. tasks. Ideally, the requirements are broken down into individual tasks according to their priority, which should not take longer than one working day. Temporal and technical dependencies should be avoided as far as possible in order to enable parallel processing of tasks. In practice, it can be useful to break down some requests iteratively only during the Sprint in order to be able to use new findings. Tasks are not assigned to individual developers by name.
• Visualisation of the tasks with a taskboard. Here the approaches differ: either a physical taskboard is used to implement the stories and tasks or software is used. The haptic of the story and task boards speaks for the physical solution, the traceability and revision security for the use of a software.
• Development of an implementation strategy, e.g. the definition of classes, interfaces, test cases and unit tests.

At the end of phase 2 the team should be able to explain to the Product Owner and the Scrum Master how they want to work as a self-managing team to reach the Sprint Goal and create the expected increment.

Timeboxing in Sprint Planning

Timeboxing is a central element in Scrum. The Scrum Guide says the following about Sprint Planning: “Sprint Planning is timeboxed to a maximum of eight hours for a one-month sprint. For shorter sprints, the event is usually shorter”. This results in a timebox of 2 hours for a one-week sprint, 4 hours for a two-week sprint, etc. The hours should be divided equally between the two planning phases, i.e. with 8 hours for a 4-week sprint 4 hours for Spint Planning 1 and 4 hours for Sprint Planning 2. It is the task of the Scrum Master to ensure that the timebox is adhered to.

These timeboxes are to be understood as a guide – companies have the freedom to define other times. However, the main focus of Sprint Planning should be the definition of the work packages to realise the agreed requirements and not the time that could possibly be saved during planning.

Tips and Tricks for Sprint Planning

There are a number of experiences that teams gain in the course of a development. They become better at estimating effort or can more easily anticipate disruptions. Here are some tips for sprint planning:

• Agree on a percentage of capacity for bug fixes and support work.
• Take effective working days into account when planning. Make a note of team days off, holidays or other events that could affect sprint delivery.
• Some organisations use due dates, as using due dates can be a good mechanism for driving and tracking progress. It can also be useful for testing and stakeholder communication.³
• Make sure you use a Definition of Done, as this leads to a better Increment at the end of each Sprint.

Planning of Potentially Shippable Increments

It is difficult to predict the future, despite all experience and techniques. The reality is that even planning a simple software development project is a challenge. There are many different variables to consider and it is very easy to misjudge the effort required to realise a requirement. As a result, companies often fail to deliver on their promises.

Teams underestimate the complexity of developing solutions, correlations in requirements are overlooked or technical difficulties simply cannot be solved easily. Typical project planning uses buffers to allow for the unexpected. The underlying hope is that the buffer is large enough and that the unexpected will not happen. How can you avoid this mistake? Scrum defines the creation of potentially deliverable Increments at the end of a Sprint. This way you minimise the risk, because if something really unexpected happens, there is still a chance to take advantage of what has already been developed.

Impulse to discuss:

How important is the “Why” and the associated Product Goal for Sprint Planning in your view?

Notes:

[1] You will not find the term “Selected Backlog” in the Scrum Guide.
[2] Since the Scrum Guide does not discuss the estimation of Backlog Items, you will not find the terms Story Points, Person Days or T-Shirt Sizes in the Guide.
[3] Due dates are of course not part of the Scrum Guide.

Here you can find a video about Sprint Planning by Mike Cohn.

And here you will find additional information from our Smartpedia section:

t2informatik develops and modernises software as a service provider. Click here to learn more.