A common problem for Scrum teams is having a good understanding of what work is complete by the end of the sprint. Testing, especially automated integration testing, is a challenge, so teams often end a sprint with a few items coded but not fully tested. Since the goal of a sprint is to have a deliverable increment of work, skipping tests isn’t a good idea.
There are a variety of ways teams try to address this, including changing what “done” means and stretching boundaries of a sprint. The most effective approaches are the ones that work within the Scrum framework.
If a team has excellent automated unit and integration testing, the line between “coded” and “tested” is narrow: Commit the code, tests run, and passing tests mean success (assuming that the tests correctly verify what the product backlog item describes). But in many cases, this level of automation isn’t always present. And even when the automation level is high, there may still be things that are best tested manually.
Some teams might suggest strategies such as parallel testing sprints, “ending the sprint” and having a testing and integration period before the next sprint, or even extending the sprint to allow for more testing time. These may be short-term solutions, but they probably won’t improve your process. Changing the definition of a sprint to make the work fit also violates the whole point of a sprint: to deliver a new increment of work.
An approach that is consistent with the Scrum framework is having the planning process take testing into account. The focus of planning is often on what to build on a feature-by-feature level, but there is little discussion about interrelationships and dependencies, including for any manual testing. Instead, take the ideas of the sprint goal and the cross-functional team seriously, and invest some of your planning time in discussing how to do the work and test the results.
When team members discuss how to work together so that work requiring more manual or integration testing can be done early and they can stage and estimate work with that in mind, it’s easier to deliver features at the end of the sprint. The team may decide that coding is done two days before the end of the sprint to allow an all-hands effort on manual testing. But the sprint ends when the work is tested and delivered. You can get to done and still respect the sprint boundaries.
While it’s ideal to have an ethic where team members work together to achieve a goal and not just focus on their own work, this is often not how non-agile teams operate, and moving to Scrum is a change. Keeping the focus on how your team can deliver within a Scrum framework can help you encourage the cultural shifts that enable Scrum to add value to your organization.
If you embrace the pillars and values of Scrum and all that they imply, Scrum can help you deliver. Scrum takes discipline to do well, but effective change is rarely easy.
