Test capacity prohibiting stretch goals

Question

In my current team of 3 dedicated testers and 3 dedicated developers we often find ourselves in a scenario towards the end of our sprint (usually the last 2-4 days of our 2 week sprint) where the developers have nothing to do yet cannot commit to any stretch goals because the testers are at full capacity testing the code written in the first half of the Sprint.

We have on occasion been asked to just commit to development work on a particular story but this feels wrong as it isn't potentially shippable at the end of the Sprint and we end up having a test only task for this story in the subsequent sprint. We have also tried asking the developers to test (this hasn't gone down well), but in any case the stretch task (based on the estimates) still won't fit into the Sprint.

I have a feeling that this is a common problem in SCRUM but I can't any solutions to this. I would appreciate if anybody has any experience in dealing with this situation.

Answer 1

Here are some things that we've found that help with this situation. Of course this relies on our definition of tester and developer, which may differ from what those roles do where you are.

1. Ensure stories are being appropriately sized. It is easier to avoid the problem you discuss if your stories are truly stories rather than epics disguised as stories. If you are 4 days away from the end of your sprint and you have no backlog items that can be pulled in because they won't fit, then story size could be an issue.

2. Have testers involved in stories from the start. Make sure that backlog grooming includes one or more of the testers to ask questions that the developers may not think about. When a story begins in a sprint, make sure to have a tester go through the story with the developer. The tester may not be able to perform their testing until the developer is done, but the tester can be planning the test cases that they will be running (or automating) and can think through the steps needed by those test cases.

3. Have developers writing automated tests paired with testers. Testers are likely better at understanding what needs to be tested, but they can probably test things faster if they have a developer to help them automate them.

4. Developers can address technical debt. Are there smaller bugs, refactoring, or optimizations that the developers can address without adding to the testers workload?

Answer 2

Scrum expects cross-functional team members, when developers do not help with the testing part of product backlog items, then they are not cross-functional. Everyone should focus on getting work done, its a team effort.

I get the feeling you guys are doing "Mini waterfall" in short iterations and pushing testing to the end. Its hard to turn around a culture to prevent mini waterfalls, but a Sprint is not a mini waterfall.

Keeping tasks small will help if you have to keep seperate roles between creating code and testing. Testers can start testing after the first tasks are done. Trying using INVEST to define upcoming sprint backlog items to keep them small and testable.

There are always some tasks developers could do during any downtime:

1. Write and extend automated (unit) test-cases coverage
2. Create spikes for upcoming features in the product backlog
3. Improve API documentation

Update

Another possible solution for your problem is a branching strategy.

• Work in feature branches
• Merge features into a test branch
• Merge tested features into a release/sprint branch

This makes sure that the release/sprint branch is always in a releasable state, and that it does not contain any unfinished work. At the end of sprint you release all finished work and you can continue with any unfinished work in a new sprint.

Answer 3

This is a very common problem with Scrum. The only way to completely eliminate this issue is to switch to Kanban :).

Some ways to alleviate the scenario you describe are:

1. Mix and match the stories within your iteration so that it contains a number of different sized stories. This helps ensure smaller stories can be checked in sooner allowing testing to begin and not leading to a rush at the end of the sprint to test everything.

2. Have your dev team write happy path automated tests before they can commit to trunk

3. Have devs become testers when a certain work in progress limit is reach for stories in "testing" state (I know, you said this was unpopular)

4. Have a number of tech debt or minor defect fixes mixed into the iteration that do not require extensive manual or automated testing (not always possible, but devs can usually provide ideas about refactoring or enhancing code during a retrospective)

As an aside, consider that having a little developer slack at the end of an iteration is not always a bad thing. Take this time as an opportunity to get devs reviewing upcoming iteration stories and defects for completeness, have a pre-estimation exercise, fish for tech debt and enhancement stories, write automation tests for previously fixed defects or newly discovered edge cases, take time to do code reviews, and most importantly reflect on the quality of the work that was committed in the current iteration.