Technically, nothing in The Scrum Guide says you can’t pick a particular purpose for a Sprint, so long as you are developing something of demonstratable value to your customers and stakeholders. However, some practices I have seen make me raise an eyebrow. Here are some examples:
Design Sprints
Why would a team have a separate “design” Sprint? By having a designated Sprint just for creating a design, the team is missing the concept of “working product,” which should be the outcome of any iteration.
If all you get out of a Sprint is a design, but nothing works, is it truly valuable? Is it potentially releasable? I think not.
Preparatory Sprints
Also sometimes called “Sprint 0,” this is usually an un-timeboxed period in which the team forms, and sets up the infrastructure, tools, etc. that they need before they start executing. There are a couple of things wrong with this.
First, if prep work must happen, it should just happen – it shouldn’t be wrapped in the label of a Sprint because it’s not one. This groundwork needs to be in place before the team starts sprinting.
Second, no stakeholder cares that you now have everything ready to start developing. As far as they’re concerned, you just wasted a bunch of time and didn’t have anything to show for it.
Integration Sprints
If you need a particular Sprint for integrations, you’re undoubtedly doing Scrum incorrectly. Remember that every item in the Product Backlog should represent a vertical slice through all system layers (including integrations).
Not only is having an integration Sprint a bad idea, but it’s also risky. Having a special time to do this work implies that it hasn’t happened before, and the entire thing needs to be tested to ensure the interoperability works smoothly. And if it doesn’t, well, you know what happens (nothing good).
Hardening Sprints
A “hardening” Sprint implies that the system isn’t stable and quality problems need to be fixed before you release it to your customers.
Quality must be baked into your agile practices, and every Product Increment adds to the previously built increments; each should be tested before being considered “done” (assuming you have a Definition of Done).
User Acceptance Sprints
If you wait until the end of a project to show your product to your customers, it’s too late. How did you decide what was important to your customers without getting feedback?
User feedback is essential to the success of any agile endeavor. Product Owners must talk with and share the progress of the Scrum Team’s work with customers and stakeholders. That’s what a Sprint Review is for.
If you don’t have the Voice of the Customer represented, your product will most likely be way off the mark, and they won’t be happy.
Final Thoughts
Every Sprint should produce something that works and provides business value; if not, then you’re missing the point of Scrum and incremental and iterative development. Don’t make a habit of having any of the above “special” Sprints.
What do you think? Does your Scrum Team have uniquely designated Sprints for specific types of activities? If so, what were they for? Are there any other types I missed? Let me know in the comments below!