What is Sprint in Scrum? Sprint in Scrum Structure

Several smaller events make up a Sprint in Scrum. Sprints, in turn, form together a path aimed at developing and releasing a Product. Each Sprint has a specific Sprint Goal and a Sprint Backlog maintained by the Development Team.

What is Sprint in Scrum – table of contents:

Sprint in Scrum – Introduction
Sprint in Scrum Structure
Sprints and the three pillars of empiricism
Transparency
Inspection
Adaptation
What changes to make during a Sprint?
Sprint in Scrum – Summary

What is Sprint in Scrum?

Sprint is the largest of the events in Scrum, which we wrote about in this article. Sprints follow a continuous cycle from the beginning to the end of work on a Product. And each iteration brings the team closer to achieving the Product Goal.

Each Sprint has a specific Sprint Goal to ensure consistency in the work of the Development Team. It takes the form of a business goal and answers the question “Why?”, “To what end?”, or “Why?”.

The workflow of a Sprint is documented in the Sprint Backlog, which lists the work needed to achieve the Sprint Goal. Its detailed description can be found here.

Sprint in Scrum Structure

Each Sprint has a specific structure and includes the following events:

Sprint Planning – the Sprint starts. During this event, the Scrum Team selects the planned work from the Product Backlog to be done in the new Sprint
Daily Scrum – a daily event where Developers plan the tasks for the day
Sprint Review – open to Stakeholders, held on the last day of a Sprint. Its purpose is to summarize the Sprint in terms of progress on the Product
Sprint Retrospective – the closing event of a Sprint, where the Scrum Team discusses the ways of working and ideas for improvement

The repetition of Sprint events promotes the implementation of good organizational practices. In other words, the Scrum Team implements the routines necessary for effective planning and, while working, draws attention to problems that can be discussed at appropriate events.

Sprints and the three pillars of empiricism

Sprints render the Scrum Team to break down the work on the Product into equal time segments lasting no more than a month. This fixed framework reinforces the three pillars of empiricism:

transparency
inspection
adaptation

We wrote about the three pillars of empiricism and their role in Scrum in more detail here. But today, we will look at how they apply to Sprint and its structure.

Transparency

Splitting the work into Sprints enhances transparency as all the people involved can get the required information about the status of the Product work in each Sprint. Sprint Planning and Sprint Review, the beginning and the end of a Sprint, combined with an update of the Product Backlog, provide all stakeholders with valuable insights into the current status of the Product.

Inspection

By dividing the work into Sprints it is possible to frequently monitor its progress. This promotes the constant identification of problems in two key areas. These are:

issues related to the achievement of the Product Goal – at the start and end of the Sprint, i.e. during Sprint Planning and Sprint Review
obstacles in the way the Scrum Team works – during daily meetings and at the end of each Sprint, i.e. during Daily Scrum and Sprint Retrospective

Adaptation

Adaptation is a very important part of the Scrum Team’s work, as it allows to solve the problems identified during the inspection. During each Sprint, Daily Scrum and Sprint Retrospective provide a safe space to talk about how to improve the Scrum Team. Implementing proposed solutions happens immediately or at the start of the next Sprint.

Sprint Planning and Sprint Review create a safe space for discussion concerning the Goals and methods to achieve them. A good self-managing Scrum Team successfully figures out what and how to implement for the next Sprint.

What changes to make during a Sprint?

Every Sprint leaves enough space for Scrum Team to improve and improvise the way they work. Therefore, identify what to change during a Sprint. The Scrum Guide does not provide a list of such changes. However, the notion of empiricism provides guidelines to follow and adapt to the way a particular Scrum Team works.

All changes can jeopardize the achievement of the Sprint Goal. According to the first rule, during a Sprint you cannot, for example, reduce the number of to-dos in that Sprint, or significantly change their characteristics. A Sprint is closely tied to the Sprint Goal. Therefore, when the Goal changes, we should abort the Sprint. However, this hardly ever happens as the only reason for a Sprint to fail is when the Objective becomes obsolete. Keep in mind that the decision to terminate a Sprint belongs solely to the Product Owner.
The quality of work cannot be compromised. This rule is intended to prevent work done during a Sprint from becoming an Increment because it does not meet the Definition of Completion. Reducing the quality of work can result in the Sprint Goal being ostensibly met, but the way individual tasks get completed does not meet the quality standards set by the organization or required by Stakeholders.
The Product Backlog can become detailed. While working on a Product, the knowledge about it increases. Therefore the detail of tasks to perform increases naturally. Therefore, it is an acceptable and even advisable change during a Sprint to detail the Product Backlog.
The scope of work may get clarified or renegotiated. This change, like the previous one, involves a growing understanding of the nature of the work being performed. The Development Team can do it in consultation with the Product Owner. However, the basic condition for its introduction is the lack of conflict with principles 1. and 2.

Sprint in Scrum – Summary

Sprint is the cyclic Scrum event that contains all the others. It has a sub Sprint Goal separate from the Product Goal. And the Sprint Backlog is different from the Product Backlog. The nature of Sprints is cyclic. The fixed length of Sprints is conducive to maintaining good workflow practices and nurturing the three pillars of empiricism. During a Sprint, the Scrum Team cannot change its Objective. It can, however, refine the Product Backlog and as knowledge grows, refine and negotiate the scope of work.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.