Agile has a problem with names. “Agility” is often interpreted as “speed”; however, the better, more accurate meaning is “flexibility”. Think about it, what is more agile, a scooter or train going full speed?
In the case of Scrum, some interpret “Sprint” as a crazy, high-speed race. In reality though, it refers to moving around a track at a pace that is fast enough to not to be left behind, but sustainable enough to be able to finish the race and then, yes, to sprint.
Scrum is a framework, not a methodology, that continues to evolve. Over the years, the framework has been updated to incorporate learning from different sources, and especially from the experience of the teams that have applied it. One element that has not changed, though, is the use of the Sprint. Sprint (also known as iteration) has been part of Scrum since its inception and has never been questioned for good reason: it is the connecting element of everything else.
What is a Sprint?
The 2020 Scrum Guide (which gets shorter with each edition) says: “Sprints are the heartbeat of Scrum, where ideas become value.” So, without Sprints, Scrum doesn’t work. Its importance is clear, but what exactly are we talking about?
Sprints are “fixed length events” limited to one month, although it is customary to set the sprint at 2 or 3 weeks. The purpose of these fixed-duration cycles or iterations is to “create consistency.” Scrum is a way of working that puts the spotlight on the importance of value creation. For this reason, it minimizes uncertainty with a series of fixed and established meetings or events that occur at predictable times and whose mechanics are known. Some might complain that Scrum “has a lot of meetings.” However, I believe that the alternative (meeting on demand, without knowing in advance when and with changing agendas) is infinitely worse. For more on this rebuttal, see How to Take Advantage of the Daily Standup and Avoid the 7 Deadly Sins.
The Sprint creates consistency and reduces uncertainty to give prominence to what is important: creating value.
What happens in a Sprint?
All the iteration work aimed at delivering value is done during the Sprint. To ensure alignment, and a sustainable pace, there are a series of meetings that mark the beginning and end of work and the crucial synchronization of the team: Planning, Daily Meeting, Review, and Retrospective (and any other that a team considers necessary for its proper functioning). In all, and in the worst case, according to the Scrum Guide, almost 90% of the sprint time is available to do the actual work. The rest is dedicated to planning, detecting impediments, contrasting results, improving the way of working, aligning the team and the expectations of the stakeholders, etc.
Each of Scrum’s “responsibilities” has a relevant role during the Sprint:
- The PO or Product Owner manages the backlog, talks with the stakeholders, and is accountable for maximizing the value of the team’s product.
- The SM or Scrum Master seeks to maintain an effective workflow by eliminating barriers and also supports the team as a servant leader and coach.
- The developers (which is the term used in the Guide, although it clarifies that all the necessary profiles must be on a team, and not only programmers) translate the business needs, which are expressed as elements of the backlog, into value for the end users of the product or service.
The Sprint culminates in a Product Increment, or at least added value to the existing increment, although we do not necessarily wait until the end of the sprint to be able to release an increment of the product to its users.
What guides the work in a Sprint?
Each Sprint starts with a goal that aligns expectations, anticipates results, and helps the team focus on what’s really important. To do this, the Sprint becomes a stable environment. And this means not introducing changes that put achieving the goal at risk. (It must be said though that nothing prevents refinement and negotiation with the Product Owner as the work progresses and more is learned. And of course, that the quality remains stable and is not disputed.)
The Sprint goal sets the course and defines the purpose, which will contribute to team motivation. Working without knowing “the why” can lead to frustration and lack of ownership and can demotivate the team.
Of course, there may be exceptional circumstances in which that objective is superseded by another or becomes unattainable without a way to redirect it. It this time, we can propose that the Sprint is cancelled, but it is up to the PO to do so.
How long is a Sprint?
Although the Scrum Guide only defines that the Sprint should last “a month or less”, experience and the Guide itself tells us that the duration has a lot to do with the goal of reducing uncertainty and risk.
The Sprint, such as a cycle or iteration, helps to generate stability but, above all, is generating learning.
Scrum is, let’s not forget, is “a lightweight framework that helps… generate value through adaptable solutions to complex problems”. If the problem we face is laborious and complicated, but has a clear, repetitive, and well-known recipe solved it, Scrum might not be the right framework to address it.
However, if there is uncertainty, holes in the description of the problem, and lack of knowledge in how to solve it, this is where Scrum is most valuable in solving the problem. Scrum allows us to constantly test the waters by asking ourselves if we are on the right track.
Duration has a lot to do with this. When we move into an environment of great uncertainty, we have to check more frequently if we are on the right track and whether we need to introduce changes and adjustments. A month-long sprint implies that we are moving on very firm ground. At the other extreme, in an extremely volatile environment, we could reduce its duration to a week or even less (there are examples of exploratory activities with one-day sprints).
Most common though, is to work within durations of 2 or 3 weeks (the Guide expresses a preference for the shorter duration). There are even scaling frames that set a certain duration. The time limit that a team adopts should be based on their own experience and needs. But what should be clear though is that the duration of the Sprint is not adjustable or changed on demand. The Sprint is a fixed and stable timeframe, so its duration should not be subject to fluctuations.
The Sprint is Scrum’s structural element. Playing with its stability makes Scrum weak and useless.
Beyond the Sprint
Dig in to Scrum in our Agile Fundamentals course. Learn all the terminology, ceremonies, principles, techniques, and day-to-day application of Scrum. (And, earn your ICAgile ICP certification!)