Yup – I said it, and I mean it – there should be no “special” Sprints in Scrum. The Scrum Guide is quite clear that the goal of every single Sprint is to create a working increment for inspection, which is potentially releasable. It must also be valuable and demonstratable to your customers and stakeholders. If your increment doesn’t display tangible business value, you’ve missed the whole point of Scrum.
As a consultant, I have seen many egregious practices, some of which are bad habits to break. Let’s explore what not to do when Sprinting:
Sprint 0
The dreaded Sprint Zero (of which there is great debate amongst agilists) is typically an unspecified amount of time used for preparation, planning, resourcing, and set up before a team feels it’s ready to start sprinting.
Using a preparatory Sprint is a lazy way to start a project or product; however, I also understand reality. Sometimes organizations need time to get buy-in, budget, the right people, tools, and infrastructure to set a new Scrum Team up for success before they start sprinting.
That said, don’t label this period “Sprint Zero” because it’s not a Sprint (it lacks a defined time-box with a specific goal and doesn’t usually produce a valuable working increment). If you need prep time, be honest about what it is, and only start sprinting when everything is ready.
No Sprint 0!
Sprints of Different Lengths
Your Scrum Team should decide its own sprinting cadence; the organization should not prescribe this. Some teams may perform more complex types of work, necessitating longer Sprints, but it’s up to the team to make that decision.
Regardless of how long your Sprints are, it’s a horrible idea to use irregular Sprint lengths that vary Sprint-by-Sprint. The time-box for your Sprints should be consistent, predictable, and indefinitely sustainable. If your team constantly changes how long their Sprints are, you lose all these benefits of Scrum.
So, pick a Sprint length, and stick to it. Or, if at some point the team discovers they need more or less time per Sprint, they can negotiate as a team and experiment to determine their ideal time-box. But this should not be a regular occurrence.
Design Sprints
Few things irk me more than hearing about companies using “Design Sprints;” this is a fallback to waterfall ways of working, in which you must decide everything before making any progress toward a working product.
These types of Sprints are not only a bad practice but also imply that specialists (presumably designers) are part of the Scrum Team for only a short window of time. If the idea of Scrum is to have fully cross-functional teams, this doesn’t exactly work. What happens later when customers or the Product Owner provide feedback, and you request design changes? Who will do that work without the skill existing on the team?
The Agile Manifesto also states, “The best architectures, requirements, and design emerge from self-organizing teams.” Need I say more? It’s just a bad idea, so don’t do it.
QA or UAT Sprints
Again, harkening back to traditional Project Management, all the testing happens at the bitter end. Testing time is often compressed due to problems with development, and you cut the one thing that should never be compromised: quality.
Whether this is a QA problem or end-user testing issue, it doesn’t matter – there should be no special Sprints reserved just for testing.
Another fundamental agile principle is that the quality of the product should not be diminished; quality is – in essence – baked into agile processes. Every “done” increment should be critical defect-free and potentially releasable.
Integration Sprints
So… you have a bunch of systems that must work together and communicate with one another – you’re not unique. Every system has complexity like this, and therefore every Scrum Team will face the integration issue.
Like testing, integration should not happen at the end of a project or product development. Integration should occur in every single Sprint.
Remember the “slicing the cake” concept? Having an “Integration Sprint” is like building separate system layers rather than taking a thin vertical slice through all the layers to create a small, working piece of software. Be sure you don’t fall into this trap.
Hardening Sprints
Is your system unstable? Did you accumulate a lot of intentional (or unintentional) technical debt that’s preventing the Product Owner from feeling comfortable about releasing? How about a “Hardening Sprint” to work all the final kinks out of your solution? No!
Having a special Sprint at the so-called “end” of development implies that the product won’t be developed or maintained any longer. If not, then what’s the point? In today’s modern product world, after release, your product will quickly fade into obscurity as your competitors continue to innovate and iterate.
While a Product exists, it has a Product Backlog and ought to be maintained. Eventually, its useful life will end, and it will be retired, but until then, it’s never considered complete.
Final Thoughts
Every Sprint in Scrum should deliver a high-quality, working product increment that is a concrete stepping stone toward accomplishing the overall Product Goal. Sprints are the same length, are consistent, and include a Sprint Goal. There are no “special” Sprints that don’t deliver on the promise of incremental and iterative development.
Now, it’s your turn! Have you seen Scrum Teams or organizations exhibit any of these bad habits regarding Sprints? If so, I would love to know, so please share in the comments below!