Sprint Planning

What is a Sprint Planning, who participates, which phases exist and what is the ideal process?

Sprint Planning Definition

As an agile process for software development and project management, Scrum describes an incremental, iterative approach. An iteration is called a sprint. At the beginning of a sprint, sprint planning (also known as a sprint planning meeting or sprint planning session) takes place as a kick-off. It is a meeting to plan the requirements and work packages to be implemented in the current sprint. The prerequisite for the meeting is a maintained and prioritised product backlog. It serves as a source for creating a selected backlog with the most important and highest ranked requirements. The Selected Backlog is a wish list of the product owner. The development team decides how many and which backlog items are included in the sprint backlog and subsequently actually implemented.

Participants in Sprint Planning

Sprint planning involves the development team – i.e. all developers, the Scrum Master and the Product Owner. The meeting is organised by the Product Owner, moderated by the Scrum Master, who is responsible for the adherence to the agreed process and the communication between the participants. Stakeholders such as users, partners, sales or marketing representatives can be invited to the Sprint Planning, but they should behave passively. Ideally, the product owner has already discussed the content and significance of the requirements with the stakeholders before the meeting.

Sprint Planning

Sprint Planning as Scrum Event

Scrum is a communicative process with various events that are carried out within a sprint. These include beside the Sprint Planning, the Daily Scrum, the Sprint Review and the Retrospective.​ The Backlog Refinement respectively Grooming is also carried out regularly. The number of events shows that communication, the discussion of development and working on jointly agreed goals are very important. No event is more important than another, because we always pursue our own goals and thus a concrete purpose.

Sprint Planning in Practice

Sprint Planning 1

Sprint Planning is divided into two phases or parts: Sprint Planning 1 and Sprint Planning 2. Sprint Planning 1 deals with “what” – what is to be done. It consists of the following steps:

  • Vision of the Sprint – presented by the Product Owner. The vision gives the development team an overall view and a better understanding of what the next sprint will be about. Even if the Scrum Guide does not explicitly require this step, practice shows that the orientation towards the vision helps the team to achieve the sprint goal. The longer a sprint lasts, the more important this orientation becomes. The sprint goal is the result of the vision.
  • The product owner names the items in the selected backlog and then discusses them with the development team. The aim here is to identify business and technical backgrounds and relationships and to gain an idea of the feasibility of the requirements.
  • Refinement of acceptance criteria for user stories, formulation of concrete acceptance tests if necessary.
  • Cost estimation for the realisation of user stories by the development team in person days, story points or T-shirt sizes.
  • Transfer of the discussed requirements into the sprint backlog, taking into account the maximum number of tasks to be realised. If the sprint backlog is “full”, the estimate of further requirements can be postponed to the next sprint planning.
  • Commitment of the development team, i.e. an obligation of the team to realise the discussed requirements in the course of the sprint.

Phase 1 of the sprint planning ends with the commitment of the team.

Sprint Planning 2

With the commitment of the developers, the task of the product owner in sprint planning is completed. In part 2 of the meeting, the developers discuss the technical details of the user stories to be realised without the product owner, who should, however, be available for questions, and without the possibly present stakeholders. The Sprint Planning 2 deals with the “How”, i.e. the question “how” the agreed requirements should be implemented. The following steps are carried out:

  • Structuring the user stories into work packages – i.e. tasks. Ideally, the requirements are divided into individual tasks according to their priority, which should not take longer than one working day. Time and technical dependencies should be avoided as far as possible to enable parallel processing of tasks. In practice, it can be useful to break down some requirements iteratively during the sprint in order to take advantage of new findings. The tasks are not assigned by name to individual developers.
  • 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 haptics of the story and task cards speak 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 will work as a self-organising team to achieve 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: “The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.” In other words, the Scrum Guide recommends 2 hours per one-week sprint, so 4 hours for a two-week sprint, and so on. The hours should be distributed equally between the two planning phases, i.e. 4 hours for Spint Planning 1 for a four-week sprint at 8 hours and 4 hours for Sprint Planning 2. It is the task of the Scrum Master to ensure compliance with the timebox.

These times are to be understood as orientation – companies have the freedom to define other times. In the foreground of sprint planning, however, 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 predict disruptions. Here are some tips for sprint planning:

  • Arrange a percentage of capacity for troubleshooting and support work.
  • Plan with effective workdays, note team days off, holidays, or other events that could affect Sprint delivery.
  • Some organisations use due dates because using due dates can be a good mechanism to drive and track progress. In addition, it can be useful for testing and stakeholder communication.
  • Make sure you use a Definition of Done as this leads to better software at the end of each sprint.


Challenges for Companies

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 that need to be considered, and it can easily happen that the effort to realise a requirement is misjudged. As a result, companies often fail to deliver. Teams underestimate the complexity in developing solutions, correlations in requirements are overlooked or technical difficulties simply cannot be solved easily. Typical project planning uses buffers to take the unexpected into account. The underlying hope is that the buffer is large enough and that the unexpected does not happen. How can you avoid this error? Scrum defines the creation of potentially shippable software increments at the end of a sprint. This minimises the risk, because if something really unexpected happens, there is still a chance to take advantage of what has already been developed.

We are happy to provide you with knowledge, experience and 100% passion for your software development and requirements analysis. We help you with the collection, structuring and administration of requirements and pay attention to consistency, completeness and traceability. We support you in identifying technical correlations and consider stakeholders, goals and boundary conditions. And we plan and control your projects with these requirements on the basis of defined processes.

Find out more about software development here  »

More details and information ...