Skip to content

Theory "Sprint Planning"

Scrum Events

There are five Scrum Events in a Scrum project - some of which you have already encountered during this online course, others you will come across in the rest of the course. The Scrum Events are:

  • Sprint
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

The four Scrum events Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective refer to the respective Sprint and take place within the framework of the respective development interval.

What is to be done in the upcoming sprint?

At the beginning of each Sprint, the so-called Sprint Planning Meeting takes place. As the name suggests, the upcoming Sprint is planned in this meeting, which brings the product development one step closer to the Product Goal.

In principle, there are three questions you should ask yourself as part of the Scrum Team during the Sprint Planning Meeting:

  • Why is this Sprint valuable?
  • What can be accomplished in this Sprint?
  • How should the selected tasks be completed?

During the Sprint Planning Meeting, entries are selected from the previously created Product Backlog which have been prioritised by the Product Owner. The selected entries are to be processed in the upcoming Sprint and are transferred into a deliverable Increment.

Increment

The Increment is a Scrum Artefact. The corresponding commitment is the "Definition of Done". An Increment is a concrete step towards achieving the Product Goal and the goal of each Sprint. An Increment is a tested, usable or saleable part of a product. All work that does not meet the Definition of Done is not considered an Increment.

At the end of each Sprint, the generated Increments are approved by the Product Owner in the Sprint Review and reviewed by him, by the Developers and any stakeholders who may be present. It is also possible to deliver an Increment to the stakeholders before the completion of the Sprint.

Good to know

Ultimately, the sum of the Increments results in the final product, which is described by the Product Goal and specified in the Product Backlog.

The Definition of Done

An essential aspect in the processing of Sprints is the requirement that a Sprint is only successful in its entirety if all user stories have been fully converted into an Increment and then presented in the Sprint Review. Even if not all user stories have been implemented, the Sprint can be defined as "Done" if the Sprint Goal has been achieved.

Definition of Done

The "Definition of Done" (DoD) is an important agile tool that helps teams plan and execute work. Basically, the DoD is simply a set of criteria that the product must meet in order to be considered done.

The DoD criteria that all implemented user stories in the Increment must meet can be:

  • Business-,
  • Functional-,
  • Quality- and
  • Non-functional requirements.

They can also be defined by the Developers in consultation with the Product Owner.

Examples of "Definition of Done" criteria:

  • The Sprint Goal has been achieved according to the Scrum Team's evaluation (this may also be the case if not all user stories have been implemented).- The acceptance criteria of the implemented user stories are fulfilled.
  • The release documentation has been completed.
  • The Increment has been tested.
  • Existing guidelines, standards and norms have been complied with.

Procedure of the Sprint Planning Meeting

The Scrum Master and the Product Owner agree on the Sprint Goal.

Sprint Goal

In order to give the Developers the rough direction of the Sprint as well as a target, there is the so-called Sprint Goal. The Sprint Goal - which represents the commitment to the Sprint Backlog - is set by the Product Owner and should be known by all participants at the end of the Sprint Planning Meeting. You will learn more about the Sprint Goal in the next chapter, which deals with the Sprint Backlog.

Once the Sprint Goal has been set, the Developers go through the prioritised Product Backlog to select Product Backlog Items for the next Sprint. They start from the top, i.e. with the user story that has the highest priority. How many user stories or Product Backlog Items are selected for the next Sprint is determined by the Developers as a team. As many Product Backlog Items as the Developers estimate they can process are included for the upcoming Sprint.

The number of user stories selected for implementation during Sprint Planning is based on two parameters. Both estimations should be roughly equal in order to have a realistic chance of completing the activities on time.

  1. The net working time available; here you should also ask yourself how much time the Developers are available.

  2. The estimated working hours that were calculated for the realisation of the different tasks - here, however, you can also orientate yourself on the story points of the individual user stories that were achieved in the estimation workshop. In the end, the team decides jointly according to its instincts. The velocity of the previous Sprints should also be taken into account. Estimation plays a central role here.

... and yet estimates are often dispensed with.

You have probably already noticed in the course of this course that the Scrum framework requires you to estimate. However, you may have experienced in practice that some teams refrain from estimating. What are the reasons for this? For one thing, Developers may not be able to gain any added value or insights from estimating (especially from estimating hours), and for another, in the end, a single person - one Developer - is responsible for implementing a task, and the teams that forego estimating do not want to involve the other Developers in the decision.

You are at the beginning of a project or at the beginning of your career as a team member in a Scrum project and your estimates are far from reality? Don't take it too seriously! As the project progresses and you become more experienced, you will get better and better.
The velocity of the previous Sprints can be used in subsequent Sprints to select the appropriate number of user stories or story points for the Sprint.

After this preparation, the Developers can then focus on the transfer of the user stories into tasks in the follow-up meeting. Tasks are identified for each user story and estimated in terms of net working hours. At the end of the Sprint Planning, the Developers agree to achieve the previously set Sprint Goal, i.e. the implementation of all selected User Stories, if possible.

Overview: Sprint Planning Meeting

  • Participants: Scrum Team and possibly representatives of the customer or user.
  • Duration: maximum 2 hours per Sprint week
  • Moderation: Scrum Master
  • Responsible for the goals: Product Owner
  • Result: Goal description and Sprint Backlog of the upcoming Sprint

What will happen to the tasks?

The selected tasks become part of the Sprint Backlog. This is the result of the Sprint Planning Meeting and it gives the Developers an overview of the activities to be completed in order to implement the desired Increment.

In summary, it can be said that the Product Owner expresses his wish for the "what" - the functionality of the Increment - and the Developers are responsible for understanding this "what" and to underpin it with the "how". The Developers themselves decide how to achieve the desired ideas and which tasks have to be completed based on the findings of the Sprint Planning in order to implement the user stories from the Product Backlog.

Tip

For more complicated user stories or Epics, it may be a good idea to hold a two-part Sprint Planning Meeting in which the Product Backlog is reviewed and prioritised. The entries that are considered for the next Sprint can, if necessary, be split up and discussed in detail in this meeting.