Don’t Develop in One Sprint and Test in the Next
Updated: Aug 23
When teams first learn that every Sprint they must deliver a usable, Done increment—including both development and testing—it can feel impossible. A common temptation is to develop in one Sprint and test in the next. Don’t. The extra cost is far higher than most teams expect.
Here are the five biggest problems this creates.
Administrative Burden
You've just created a whole lot of administrative burden for the Scrum team. Now instead of keeping track of one Product Backlog item, they need to tie at least two of them together. Which seems like it's not a big deal. But if a team regularly delivers around 30 Product Backlog items per Sprint, they can suddenly find themselves tracking sixty or more items across Sprint boundaries. That’s a completely unnecessary administrative load.
Decreased Visibility
When development and testing are split across two Sprints, stakeholders experience reduced visibility into the team's progress. They have to wait longer to see what the Scrum team is working on because the work they commit to at Sprint Planning only becomes potentially releasable after the next Sprint.
Reduced Ability to Change Direction
When development and testing are separated across two Sprints, the team accumulates a substantial amount of "half-baked" work. As a result, it's a much slower process to pivot or respond to changing requirements. 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 it will take the Scrum team at least two Sprints to deliver functionality to the customer instead of one.
Increased Risk
You can think of the Sprint as a container for risk. Ideally, every Sprint, the team delivers something and then asks for feedback. If you're developing in one Sprint and testing in the next, now it’s taking the Scrum team two Sprints - instead of one - to learn that planned functionality is not technically feasible or valued by the customer. What a waste! In addition, defects found in Sprint N+1 are more expensive to fix because context has been lost.
What to do instead
Slice Product Backlog items smaller. You don’t have to deliver everything the customer ever wanted in a single Sprint—only something that is usable and meets the Definition of Done. Even a “hello world” page is fine if it is truly Done.
If the team consistently cannot produce a Done increment inside the current Sprint length, lengthen the Sprint (up to one month). As the team improves, they can shorten it again.
Conclusion
Developing and testing together in small batches simplifies delivery rather than making it harder. It reduces risk and improves visibility and flexibility. This approach sits at the heart of Agile, and it’s a key reason the approach works in the first place.
If your team is struggling to get to Done every Sprint, check out our article Three Steps to Done in Scrum.
