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