The sprint cadence is the heartbeat of the Scrum Team and the rhythm of an agile organization that has adopted the Scrum framework.
But the fact that it is not talked about and written about as much prompts many practitioners to ask: How synchronized should this rhythm be?
I have been asked this question both in the context of a single Scrum Team and multiple Scrum Teams (for the sake of simplicity, let’s consider a single Scrum Team divided into sub-teams as two separate teams).
In this post, I will give you my perspective on this topic.
Single Scrum Team
Let’s start with the question of whether or not the Sprints of a Scrum Team can overlap (to put it differently, can a single Scrum Team work on two sprints simultaneously?). The long answer short is, “no,” and we will find out why in a moment.
From the perspective of the Scrum Team, the Sprint is nothing more than a time box with a start date and an end date. Just like the hours on the clock and the days on the calendar, Sprints are sequential; they don’t overlap.
These time boxes are there to force the Product Owner and the Developers on the Scrum Team, with the Scrum Master’s facilitation, to make informed bets and hard trade-offs so that they work toward progress and not perfection.
Suppose you set out to do something for an hour, but then you don’t get it done. You don’t “extend” the hour and let it “overlap” with the next one. Instead, you admit to yourself that you planned wrong, learn lessons about what to do differently next time, and then adjust your plans to the new reality that has occurred.
By the same logic, a Scrum Team doesn’t extend a Sprint—postponing the next Sprint or letting the two Sprints overlap—because they failed to achieve the Sprint Goal. They end the Sprint and plan the next.
When that happens, the Scrum Team and their stakeholders examine the completed work at the Sprint Review and discuss what to do next.
At the Sprint Retrospective, the Scrum Team talks about what they could have anticipated, planned for, or done differently in the Sprint. Then, they return any unfinished work items back to the Product Backlog, where they may or may not get picked up in the upcoming Sprints.
Until the Sprint Planning takes place and the Product Owner and Developers discuss which work items to plan for to achieve the Sprint Goal of the next Sprint, it is unknown whether the Scrum Team will pick up all of the uncompleted work items.
The economist John Maynard Keynes is often credited with saying: “When the facts change, I change my mind. What do you do, sir?”
Multiple Scrum Teams
When two or more Scrum Teams are working on the same product or in the same grouping of products, should their Sprints be synchronized (start and end on the same days) or overlapping (start and end on different days)?
The answer to this question is anything but a simple “yes” or a “no.” And, to come to it, you need to consider several factors.
Factor #1: Are the Scrum Teams dependent on one another?
Is Team A dependent on Team B to achieve its Sprint Goals? Is this dependency synchronous (for Team A to deliver, Team B must deliver first) or asynchronous (it doesn’t really matter which team delivers first)?
If Team A must always deliver after Team B, there is a strong case for Team B’s Sprints ending a few days or a week before Team A’s Sprints (in other words, to overlap). This way, the developers in Team A have the time they need to integrate the work of the developers in Team B.
Ideally, these dependencies should be considered as part of a larger, enterprise-wide release planning cycle. A number of agile frameworks attempt to solve this problem in different ways. The most widely adopted are, in order of complexity, Scrum of Scrums (SoS), Scrum@Scale (S@S), and the Scaled Agile Framework (SAFe).
Factor #2: Do the Scrum Teams share any team members?
Do Team A and Team B share members, such as a Business Analyst, Solution Architect, or UX Designer, who must attend two Sprint Reviews and two Sprint Retrospectives?
This is often the case in large companies where subject matter experts work as part-time members of multiple Scrum Teams. Obviously, it would be a challenge for them to prepare for and attend two Reviews and two Retrospectives on the same day.
Factor #3. Do the Scrum Teams share stakeholders for their Sprint Reviews?
Do some or all of the members of Scrum Team A need to participate in Scrum Team B’s Sprint Reviews, and vice versa? It can be problematic if their Sprints end on the same day—or even in the same week.
Do the same stakeholders (external customers, organizational sponsors, agile leaders) need to participate in both Scrum Teams’ Sprint Reviews?
Although there is no right or wrong answer, the best thing to do is for both teams’ Scrum Masters to coordinate with the stakeholders invited to the two team’s Sprint Reviews, as it can be highly demanding to have to attend two of these events on the same day.
