Some teams, particularly those transitioning to Scrum from traditional waterfall approaches, really struggle with the idea of delivering fully tested increments of valuable functionality within a single Sprint. They don't believe that they can actually deliver a Done increment - including developing and testing valuable functionality - within a Sprint. Sometimes those who are newer to Scrum may decide to modify Scrum so that they split the development and testing phases across two consecutive Sprints.
I get it. Developing and testing a valuable increment of usable functionality in one Sprint can seem intimidating for those who are coming to Scrum from a predictive process like waterfall.
But here is why developing in one Sprint and testing in the next actually causes more problems than it solves.
Decreased Visibility and Predictability
When development and testing are split across two Sprints, stakeholders experience reduced visibility into the team's progress. They must wait longer to see what the Scrum team is working on, hindering collaboration and feedback. Furthermore, this approach decreases predictability as teams are effectively planning two Sprints' worth of work during Sprint Planning. Coordinating development and testing efforts across two Sprints can become burdensome, making it challenging to meet Sprint goals consistently.
Reduced Ability to Change Direction
Scrum's incremental approach grants teams the flexibility to change direction easily as they work on small, manageable increments of functionality. When development and testing are separated across two Sprints, the team accumulates a substantial amount of "half-baked" work. Consequently, it becomes challenging to pivot or respond to changing requirements swiftly. To change direction, the team must wait until both the development and testing phases are completed, which can take at least two Sprints.
Delayed Value Delivery
The Agile Manifesto's very first principle emphasizes "early and continuous delivery of valuable software" as a key principle for Agile teams. Developing in one Sprint and testing in the next introduces unnecessary delays in delivering value to the customer. If you are developing functionality in one Sprint and testing in the next, that means that it will take your Scrum Team at least two Sprint to deliver functionality to the customer, rather than one.
Increased Risk
The 2020 Scrum Guide highlights that Scrum aims to control risk through an iterative, incremental approach. Developing in one Sprint and testing in the next increases the risk substantially. It postpones feedback from customers and stakeholders potentially leading to increased investment in the development of features that customers may not find useful. Additionally, it make take the Scrum team two Sprints - instead of one - to learn that planned functionality is not technically feasible. This can result in wasted effort and resources.
Unnecessary Complexity
Separating development and testing into distinct Sprints introduces unnecessary complexity into the process. Teams must track which features have been developed but not tested beyond the scope of a single Sprint. Questions arise about whether separate product backlog items are needed for development and testing or how these items should be tied together. The lack of clear definitions can lead to confusion and inefficiency. It becomes difficult to gauge when development is truly complete.
Conclusion
Developing in one Sprint and testing in the next may seem like a reasonable compromise for teams transitioning to Scrum, but it is not aligned with the fundamental principles of the Scrum framework or the Agile manifesto and it causes more problems than it solves. Scrum's emphasis on incremental value delivery, flexibility, risk control, simplicity, visibility, and predictability makes it clear that combining development and testing within a single Sprint is the best approach. To fully reap the benefits of Scrum, teams should strive to create potentially shippable increments every Sprint, thus fulfilling the promise of delivering valuable software to customers early and continuously.
If your team is struggling to get to ‘Done’ every Sprint, check out our article Three Steps to Done in Scrum.
To learn more about the Scrum framework and value delivery, signup for Rebel Scrum's upcoming Applying Professional Scrum course. Weekend classes available!