5 Sprint antipatterns: what is Sprint?
The Scrum Guide quite clearly defines what a Sprint is (“the heartbeat of Scrum”) and clearly states what Sprint is for (“where ideas are turned into value”). Generating value is the essence of Scrum. The Sprint is a period of really intensive work after which we stop to work out where we are (inspection) and correct our course if we’re moving in the wrong direction (adaptation). Let’s find out about some Sprint antipatterns.
Sprint 0 as most common Sprint antipattern
Some Scrum teams start with Sprint 0 because “they need more time to prepare some architecture, clarify the requirements etc.” Hence, this is treated as a kind of pre-Sprint in which the main idea of Scrum is lost: there is no potentially releasable increment at the end of the Sprint.
Next Sprint is delayed
“Another Sprint starts immediately after the previous Sprint”, meaning there is nothing in-between Sprints even if the requirements are not clear enough to be pulled into the Sprint. When one Sprints comes to an end, you start another Sprint with Sprint planning with whatever you have. Product Backlog Items must refined during the Sprint.
Hardening Sprint
Simply speaking, a hardening Sprint is a special, additional Sprint intended to reduce technical debt the team has incurred in previous Sprints. An example of technical debt might be poor architecture, bad development practices, or wrong design choices. Instead of producing another increment, the team spends the whole Sprints on the matters that could probably have been avoided. There are a number of actions you can take to avoid it such as a strong DoD, automated tests whenever possible.
Sprints of different lengths
If a team decides for a two-week Sprint, it should be consistent so that the rhythm of Scrum is steady. Various Sprints lengths have an impact on planning and team’s capacity.
Separate Sprint for development and tests
This is a very wrong practice, as you will get two fake Sprints, none of which produces a potentially releasable increment. Furthermore, it makes people work in silos. During the development Sprint testers wouldn’t have enough work to do, while during the test Sprint developers wouldn’t have enough work to do – this is not something we aim to achieve. Developers are anybody who commit to creating any aspect of usable increment, so these are testers as well. Sometimes it’s better to pull less work into a Sprint to turn it into an Done increment of high value rather than taking on too much work that is not done. Not done work has no value to the user.
