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?”