Scrum Events demystified - The Sprint
Tags: agile, productivity
Published: 2020-02-02 09:36:49

---
title: Scrum Events demystified - The Sprint
published: true
description: Demystifying the most important Scrum Event and answering the most common questions
tags: agile, productivity
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/xtphb49jer1m2sqcp3u5.png
canonical_url: https://paulisaris.com/scrum-events-demystified---the-sprint/
series: Scrum Events demystified
---


post photo by [pexels](https://www.pexels.com/)

This post was originally published on my [personal blog](https://paulisaris.com/scrum-events-demystified---the-sprint/)
 
# Introduction

This post is the first part of the "Scrum events demystified" post series.
In this series, I will try to shed some light on the most common events in the Scrum framework.

First things first, let's begin by defining Scrum:

According to the [Scrum Guide](https://www.scrum.org/resources/scrum-guide):

> Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.<br/><br/>
  Scrum is a process framework that has been used to manage work on complex products since the early 1990s.<br/><br/>Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. <br/><br/>Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

Indeed, Scrum is successfully used for many years now, from teams that want to carry out risky projects in an Agile way.
 A critical part of the Scrum methodology is the Scrum Events. 
 
 All in all, Scrum (as much as most Agile methodologies) has an 
 allergy when it comes to long, pointless meetings that include 
 business people and only result in:
 
 1. Countless hours lost from what could have been productive work
 2. Developers wondering what they did to deserve one more PowerPoint presentation
 3. A ton of calories gained from the pastries that are usually served
 
![Meeting gif](https://media.giphy.com/media/3o6MbiSDt6PKFUyrlK/giphy.gif "Meeting gif")

Today I will be presenting the heart of Scrum, 
the most important of all Scrum events; ***The Sprint***.

***Disclaimer:*** Some might argue that the Sprint is **, not
 an event itself** since it merely acts as a **container** for all other 
 Scrum events. This, of course, is true, but it is beneficial to treat it as an event (or a pseudo-event) to get a better grasp of what Scrum is about. 

![Agile gif](https://media.giphy.com/media/xT1XGOGdyDrL2BTfxK/giphy.gif "Agile gif")
 
# About the Sprint

The Sprint is a **time-boxed event** (as all events are in Scrum). 
Time-boxed means that it has a **predefined, specific time span**, 
and should start and end exactly when this period dictates. <br/>

For example, the team might agree upon having one-month Sprints. 
Other teams might be more comfortable and productive with 2-week Sprints.<br/>

It is generally **up to the whole Scrum Team to decide the time span**, 
given considerations such as the team composition, the risk of the project, 
and the team members' availability.

Once the Sprint starts, the team **focuses** on the tasks that were selected for work and that will add up to the final **Sprint Increment**, for the pre-defined **Sprint Goal** to be completed.

These tasks (and the Sprint Goal) should have already been defined and agreed upon during **Sprint Planning** (another Scrum event that will be presented in the next article of the series).

During the Sprint, the team is supposed to work uninterrupted on the tasks that compose the **Sprint Backlog**. Any external changes and requests are not welcome, since they are destined to decrease productivity, and should either be discarded or be dealt with by the whole **Scrum Team**.

![Scrum gif](https://www.go2group.com/wp-content/uploads/2019/09/Meme-1.gif "Scrum gif")

# Most common questions and misconceptions about Sprints

***What is the maximum time for a Sprint? Can the team have 2-month Sprints?***

The maximum time that a Sprint may last is *one month*. Anything more 
than that decreases focus and should be broken into multiple Sprints.


***What does the team need to start a new Sprint?***

For a Sprint to start, the team needs 3 things:

1. ***A Sprint Goal***
The Sprint Goal is set during the Sprint planning and should not change during the Sprint. It describes what the output of the Sprint 
   should be and is agreed upon by the whole team
   
2. ***A Sprint Backlog***
The Sprint Backlog is the collection of tasks that should be done during the Sprint. They are picked from the Development 
   Team by looking at what the Product Owner has prioritized in the Product Backlog.

3. ***A General plan of how the team should do the work***
During Sprint Planning, the team decides not only what should 
   be done during the Sprint, but ***how*** things should be done.<br/> 
   This has to do with the **Definition of Done** the team has set for 
   the project and should be flexible enough to tolerate unexpected changes, and evolve with them during the Sprint.

![Team gif](https://media.giphy.com/media/l4EoRqcypxsvGuRk4/giphy.gif "Team gif")
   
***Who is responsible for defining the Sprint Goal for a given Sprint?***

The **Product Owner** is responsible for maximizing the value of the product 
and they manage the Product Backlog as such. <br/>
During Sprint Planning the 
Product Owner suggests the objective of the upcoming Sprint and proposes 
which Product Backlog Items will help achieve this objective.

***Can the Sprint Goal change during the Sprint?***

**No.** As the Scrum Guide states:

> No changes are made that would endanger the Sprint Goal.

If the Sprint Goal becomes obsolete or does not make sense anymore, 
then the Sprint should be canceled by the **Product Owner**

***Can a Sprint be terminated before the designated date? Who is responsible for terminating it?***

**Yes.** As I described above, a Sprint can be canceled if ** its goal becomes obsolete**. This may happen when the business goals of the company change, or the market needs dictate so.
The only person able to cancel the Sprint is the **Product Owner**.

***What if the Development Team finishes all the work that is in the Sprint Backlog?***

The **Sprint Backlog** (the collection of tasks that the team has agreed 
to carry out during the Sprint) is **subject to change**. 
<br/>If all the tasks are done ("done" as to meet the **Definition Of Done**), the Development team can choose new tasks from the Product Backlog and bring them into the Sprint Backlog.

***What if at the end of the Sprint there are unfinished tasks in the Sprint Backlog?***

This is again very common. A remark that should be made here is that 
the Development Team agrees to complete a set of tasks during the Sprint, 
but **is in no way obliged to complete them at any cost**.<br/> 

When the time is over, the Sprint is over as well. Any unfinished tasks 
do not count as part of the Sprint output and are put back into the Product Backlog. <br/>Usually, these tasks will be brought into the Sprint Backlog of the next Sprint, for the Development Team to finally complete them.

![Flexible gif](https://media.giphy.com/media/Rn1nEzE4BTdC0/giphy.gif "Flexible gif")

***What happens between 2 Sprints?***

**Nothing!** As soon as the first Sprint is over (and by "over" we mean that all of other events contained in this Sprint are done), the new Sprint begins right away.

***What if someone from the Development Team leaves the company during a Sprint?***

These changes are not common, but the Development Team and the Sprint should be Agile enough to tolerate such changes. <br/> 

Usually, there may be a decrease in productivity for some time, and some tasks might remain unfinished and go back into the Product Backlog when the Sprint ends.

# Conclusion
In conclusion, the Sprint is a time-boxed event, during which the Development Team works towards a pre-defined goal that will add value to the product (the **Increment**), and acts as a container for other 
Scrum events.

In this series, I will be clarifying all Scrum 
events and demystifying the most common misconceptions about them.

Please share your thoughts in the comments, and stay tuned for the 
next part of the series!