Are Sprints Just a Way to Organise Releases?

Are Sprints Just a Way to Organise Releases?
I’m increasingly convinced that some teams cling to Sprints / Timeboxes because they facilitate release planning. A Sprint = a mini-Release = real simple. However, continuous delivery means these “Sprints” are not real Sprints.

I used to be a great fan of timeboxes / Sprints but abandoned them when Kanban came along. I now use Continuous Delivery by Default; Timeboxes by Exception.

Despite what I think, many teams stick with “Sprints” and despite the Scrum language I’ve noticed these teams increasingly do releases mid-Sprint. They are (rightly) starting continuous delivery – after all, continuous delivery is inevitable.

This is not Scrum. These teams don’t care whether tickets run into the next Sprint or not. They are breaking a cardinal rule of Scrum – to produce potentially releasable code at the end of every Sprint. They don’t need to because they are releasing when they need to mid-Sprint.

These are not “Sprints”. The teams I’m talking about are not actually doing Scrum style sprinting. The supposed “Sprints” are not timeboxes as they do not constrain the work to fit the effort available. These “Sprints” are just measures of time.

I suspect these teams are just using the “Sprint” as a bucket for release planning. Chunk the backlog into two week blocks so they can report up the line on which features are expected to land when.

Personally I think these teams should abandon the Scrum terminology and revert to weeks and/or months on their release plan. Rather than “What will we do in Sprint 37?” they can ask “What will we do in September?”

One thought on “Are Sprints Just a Way to Organise Releases?

  1. This mid-way between continuous delivery and sprint planning seems to be a common theme and even more so with teams handling multiple work streams. Using sprints to help bucket work to a single delivery date does facilitate communication as well as control re-prioritization disruptions. Batching work planning is more effective as long as the batches are small. Also a routine/rhythm generally helps align expectations and keeps exceptions at bay.

    I do think when continuous delivery is observed during sprints, it should be accepted when it makes sense and the resources are behind it. At that point it is important to define the procedure to fast-track work. How much time is allowed for the fast-track per sprint? What is the real reason for deployments during the sprint? Are some of the dependent elements of implementation actually not in the scrum team?

Leave a Reply

Your email address will not be published. Required fields are marked *