post photo by unsplash.com

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:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is a process framework that has been used to manage work on complex products since the early 1990s.

Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.

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

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.

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.

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

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.

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.
   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.

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.
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.
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.

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.
Usually, these tasks will be brought into the Sprint Backlog of the next Sprint, for the Development Team to finally complete them.

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.

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!