Question

I have been working as a .net developer following the waterfall model. When working on, say a 12 months project, usually my team follows Analysis, Design, Coding and Testing phases. But when it comes to following the Scrum process, I don’t really understand how I need to deal with it.

Consider a sprint for 4 weeks and the backlog has 10 items. Let the sprint start now. If developers are working on some backlog items for the first 10 days, I don’t know if testing (both SIT and UAT) will require JUST the remaining 10 days to complete the work. And now our sprint does not have any time to do last minute bug fixes and only few bugs could be fixed IN THE PLANNED SPRINT.

And when we do development, how can we make sure that we keep the testing team busy apart from just preparing test cases and waiting for us to deliver the functionality?

This raises a question if we need to deliver the first task/feature within the first 3 days of the sprint, so that testers might be ready with their test cases to test that piece.

I also need to educate my client to help in adapting the Scrum process.

I need some guidelines, references or a case study to make sure that our team follows a proper Scrum process. Any help would be appreciated.

Answer 1

In an ideal Scrum team, testers and developers are part of the team and testing should occur in parallel of the development, the phases are overlapping, not sequential (doing things sequentially inside a Sprint is an anti-pattern known as Scrumerfall). And by the way, contrary to some opinions expressed here, an ultimate Scrum implementation produces DONE DONE stories so testing – including IST, UAT – should be done during the Sprint.

And no, testers don’t have to wait for Product Backlog Items (PBI) to be fully implemented to start doing their job, they can start writing acceptance tests scenarii, automate them (e.g. with FitNess), set up test data set, etc (this takes some time, especially if the business is complicated) as soon as the Sprint starts.

Of course, this requires very close collaboration and releasing interfaces or UI skeletons early will facilitate the job of testers but, still, testers don’t have to wait for a PBI to be fully implemented. And actually, acceptance tests should be used by developers as DONEness indicator (“I know I’m done when acceptance tests are passing”)¹.

I’m not saying this is easy, but that’s what mature (i.e. Lean) Scrum implementations and mature Scrum teams are doing.

I suggest reading Scrum And XP from the Trenches by Henrik Kniberg, this is very good practical guide.

_{¹ As Mary Poppendieck writes, the job of testers should be to prevent defects (essential), not to find defects (waste).}