I had a discussion in a CSM class which comes back on a regular base: When your team has trouble finishing the testing during a 2-week Sprint, what to do – a longer Sprint or test in the next Sprint. Here are my thoughts on the matter.
I believe that the answer to the problem is continuous builds and continuous testing – which requires automated tests and you may not have those. If part of your testing is manual, or so large that it can’t run after every build then your choice of testing at the end of the Sprint is the only option, but I would encourage your team to automate more tests, with a focus of those tests which will most likely show problems because of the area of the code they’re working in, or because of the nature of the work. For example, if performance is a hot issue, then automate the performance tests and run those continuously – the final testing at the end of the Sprint will less likely show show-stopping defects and you make the testing/bug-fixing an easier job so late in the Sprint.
Back to the question: longer Sprints or parallel testing in the next Sprint. There is a third option: fewer stories in the current Sprint so code and test will finish in the timebox. Let’s explore all three.
Fewer stories in a 2-week Sprint will give you fast response-to-change time but you pay for it by addressing fewer changes. If your Product Owner really likes the fast response, then give this option some thought.
Same number of stories in a 3 week Sprint: the effect is the same as for the previous solution, but the response-to-change time is 50% longer – your Product Owner has to agree to this.
Note: for both solutions to work optimally you need to encourage your coders and testers to be better as team players. The coders should plan their work in such a way that the testers can start early. Testers should be readily available to the coders to discuss (pair program) through defects. And coders being able to run tests, or testers inspecting code and hinting towards solutions will also help.
Then the scenario of coding in Sprint 1, testing in Sprint 2 / coding in Sprint 2 for testing in Sprint 3 etc. This is an optical illusion: you are creating 4 week Sprints since the Scrum definition of a Sprint is that it produces a shippable increment! The response-to-change time will be even slower than a 3-week Sprint. More importantly, you are separating your coders more from your testers, and that is the least effective way to solve the problems: you are creating a mini-waterfall, a hand-over from coder to tester, where the most effective way of working is to have the roles fully integrated.
Long story short: I’d work with the team to implement continuous testing – it will take time, there may always be a set of manual tests at the end of the Sprint, but it will produce a continuous flow of code into production and give your Product Owner the shortest response time. [amazon template=image&asin=0321967054]
Leave a Reply