I do continuous deliver, why should I Sprint?

TL;DR

Sprints are not about limiting release frequency but about providing a regular cadence for planning, communication, and predictability, even if you use continuous delivery. Scrum requires a working increment at least every 30 days, but you can release more often; Sprints help structure feedback loops and align teams and stakeholders. To stay competitive and responsive, use Sprints as a planning container while delivering to production as frequently as possible.

13 July 2020
Written by Martin Hinshelwood
3 minute read
Framework Scrum Product Development Technical Leadership
Table of Contents
Comments
Comment
Feedback
` LinkedIn WhatsApp Twitter Facebook Email
Subscribe

Many folks believe that a Sprint is an arbitrary length of time in which you create and release software. They look at their continuous delivery pipeline and say to themselves; “Why would I limit myself to shipping only once every two weeks?”

UPDATE: Scrum.org just posted my Scrum Tapas - Scrum and Continuous Delivery which is posted inline below.

[embed]https://www.youtube.com/watch?v=3XOorzoubYU[/embed]

To that I say: “Where in the Scrum Guide does it say that you can’t release every day?”

You will not find it, I know as I have looked. I work with many teams that release software on a continuous delivery model of everything from a few hours, to a few days, and often on-demand. Can you say that they are not doing Scrum? Of course not.

So why would you want a Sprint at all?

  • A Sprint enshrines your empirical process by providing a maximum delivery cadence
  • It increases communication and alignment
  • It Adds some predictability to the unpredictable nature of software by evening the batch sizes.
  • A Sprint is a container for planning!

As far as the Scrum Guide is concerned you must deliver working software at least every 30 days, but there is nothing to stop you doing it more frequently than that. Indeed continuous delivery and Scrum go together quite well in my experience.

A Sprint enshrines inspect and adapt by containing your other feedback loops:

  • Sprint Planning - Inspect the Backlog and Adapt the plan for the next Sprint
  • Daily Scrum - Inspect progress and adapt the plan for the next 24hours.
  • Sprint Review - Inspect the Increment and adapt the Backlog
  • Sprint Retrospective - Inspect the Sprint and adapt the process.

Without a Sprint when would you bring all this together? The Sprint makes the effort required to pull your work together and create a Done increment of software mandatory. It is absolutely crucial to understand that if you don’t at least have working software that meets your definition of done by the end of the Sprint then you are not doing Scrum.

If you are an awesome disciplined team then by all means do something that looks a little more like Kanban, but if you don’t have the discipline to follow the rules of Scrum, how would you expect Kanban to work.

Communication & Alignment

An additional benefit of Sprinting is that it gives a cadence that your management, and other dependant teams, can follow easily. If you are coordinating work, then having a common frame of reference, Sprint 231, will aid in communication.

Creates Predictability

Software is inherently unpredictable. The standard deviation between the amount of work required for seemingly similar tasks is so big that it is very difficult to gain predictability. A Sprint creates an artificial batch of a fixed size (or at least less varied) with a time boxed Sprint so that you can create that cadence of predictability.

Conclusion

A Sprint is a container for planning rather than releasing and while Scrum requires that you have a working increment of software at least every Sprint, there is nothing to stop you doing it more often. Indeed the recommendation from Scrum.org is that you not only ship your software at least every 30 days, you should endeavour to do so more often.

Scrum.org recently changed its mantra from “Improve the profession of software development” to “Improve the profession of software delivery” to start to enshrine the idea that delivery, to your customers, is no longer optional to get significant actionable feedback that you can reflect on.

In short, while the Scrum Guide does not explicitly state it, it is no longer optional to ship your software to production at least every 30 days if you want to stay competitive and build the software that your users deserve.

Table of Contents
Comments
Comment
Feedback
` LinkedIn WhatsApp Twitter Facebook Email
Subscribe

What to read next

Article Engineering Excellence

The Sprint is a container for Planning and not necessarily for Delivery

Explains how Scrum Sprints are primarily for planning, not fixed delivery, and discusses aligning delivery schedules, continuous deployment, …

Read article
Video Product Development Scrum

Ditching the Myth of Special Sprints: Embrace True Agile Practices for Usable Products

Explains why relying on special Sprints undermines Agile, and advocates for continuous improvement, accountability, and delivering usable …

Watch video
Signal Scrum

Scrum Myth Debunked: Unfinished Work is Allowed in Scrum

Clarifies Scrum guidelines on unfinished work, explaining that items can span multiple Sprints if the Sprint Goal and Done Increment remain …

Read article
Article Product Development Scrum

Work can flow across the Sprint boundary

Explains how Scrum teams can strategically allow unfinished work to flow across Sprint boundaries, enhancing throughput, responsiveness, and …

Read article
Article Product Development Scrum

Delivery is the only Measure of Progress in Scrum

Scrum teams must deliver working software to real users every Sprint; true progress is measured by delivery to production, not just by …

Read article
Video Scrum Product Development

Mastering Agile: 3 Essential Strategies to Boost Your Team's Sprint Success

Learn three key Agile strategies: define clear completion criteria, avoid overcommitting in Sprints, and prioritise backlog refinement for …

Watch video