- 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!
While the Scrum Guide says that you must deliver working software at least every 30 days there is nothing to stop you doing it more frequently. 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? It makes them mandatory efforts as they should be. 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 dependent teams, can follow easily. If you are coordinating work, then having a common frame of reference, Sprint 231, will aid in communication.
Since software is a creative endeavour and the standard deviation of a batch is so wide an unpredictable the addition of a fixed time container artificially created some predictability in your batches.
I would say that there is a good deal of value in a Sprint.