Scrum Events - Adaptation and Inspection Loops

Hello agile friends,

After a long time, I am happy to return with our Beyond Mechanical Scrum Series.

Last time we covered the Scrum Master role, today I would like to talk about Scrum Events and the Sprint.

 Let’s return to the core of Scrum: a framework with a team (or more teams) and associated roles, events artifacts, and rules. It contains the minimum required to address complex adaptive problems. In other words, we can add other practices that may enrich our process (if they don’t break any Scrum concept).

Scrum consists of 5 events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and the Sprint, which is a container for other Scrum events.

Each event inside the Sprint has a specific purpose and allows us to inspect and adapt something. It is also important to evince that they are time-boxed.

Time-box:

Maximum unit of time for an event. It provides focus to every Scrum event.

Aside from the Sprint, which has a fixed duration, every other event may end once its goal is achieved.

As homework I would like to ask you what would happen if each Sprint had a different duration. What would this imply in the team cadence and pace?

Ok, we know we have 5 Scrum events and each one of them has a specific purpose, allowing us to inspect and adapt (two of the three Scrum pillars) something.

Let’s start by the Sprint. 

As I said before, the Sprint is a container for all other Scrum events. Its time-box is one month or less. What is the purpose of a Sprint? To deliver a done and releasable product increment, in other words, the creation of value that will allow us to inspect and adapt our strategy towards what brings the biggest value to our customer.

“The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints”

Scrum Guide

During the Sprint, quality standards don’t decrease (remember Respect is one of the 5 Scrum values, meaning we respect our customer by not decreasing the quality of what we will deliver throughout the Sprint); no changes are executed that could endanger the Sprint Goal (we will cover this topic in a future article, for now, think of it as a compass that guides the team to achieve a common purpose); as the team faces new challenges while creating the increment, questions may arise and the Product Owner may help the team in solving them. 

Although not very common, a Sprint may be canceled in case it loses its purpose. The only person able to cancel a Sprint is the Product Owner, although he may make this decision based on the Development Team, Scrum Master or stakeholders insights.

If this happens, unfinished Product Backlog Items are reestimated and return to the Product Backlog, while the potentially releasable items are typically accepted by the Product Owner. 

Sprint Duration

How do I know what is the best duration for the Sprint where I work? Should it be 4 days, 1 week, 2 weeks, 1 month? This is an interesting and reflecting question. And it has a simple answer: you won’t know until you try and learn. Return to the basics, empiricism (making decisions based on what is known).

Consider how you break your effort, the experience of the Scrum team, the environment and how ‘agile’ it really is, market conditions… all of the above and many other points will impact your capacity of delivering value, but once again, you will only know the best duration by trying, inspecting and adapting.

What truly motivates me in working with agile is that we don’t make decisions based on dubious methods, we learn on each iteration (Sprint), and we use this learning as input for our next Sprint.

Scrum values continuous improvement so reflect to yourself if your team is always improving on a Sprint basis (communication, process, …), it may be only one inch better than the last Sprint, but it needs to be better.

BREAKING THE MYTH: A Sprint should end whenever its goal has been achieved 

 If the team achieved the Sprint goal prior to the duration of the Sprint, the team may pull new work that has already been refined from the backlog (if agreed to the Product Owner) or even refine the work that may be executed in the following Sprint. This empowers the cadence of the inspect and adapt loops we gain by using Scrum.