Spreading Work Evenly Across the Scrum Sprint

One of the most common problems facing early-stage scrum teams is when the programmers finish on or near the last day of the sprint and hand their work over to the testers. The testers are left to wonder "HOW they can possibly complete their work in such a short time?". Similarly, testers on such teams struggle with " What they are supposed to do earlier in the sprint when there is nothing yet to test?". Nearly every Scrum team goes through a phase where they face these problems. So if you are facing them now take heart that others have overcome them before you. This article is written based on Mike Cohen Talk to make suggestions as to "How you can resolve the above problems?"

The first suggested solution is to get the Development Team (DT) out of the habit of finishing an entire product backlog item before handing it over to the testers. Therefore, handoffs should be as small as possible. The second approach is making the problem more visible in the DT's room or Project home page if the DT is distributed. Finally, helping DT learns a new way of collaborating with each other through the Swarming technique. Now, let's discuss each of those approaches.

• How can DT have smaller Handoffs? 

As a Scrum Master, you should be able to get the programmers out of the habit of finishing an entire product backlog item beforehand it over to the testers. a good Scrum team has to do a little bit of everything, every day. Therefore, some analysis, design, coding, and testing must be done daily. To make this a reality, it is important for team members to reduce the size of handoffs.

Let's consider the case of a programmer and tester (This example can also include other members such as UI designers, database engineers or any number of others). If a programmer and tester are new to scrum, it's likely the programmer will grab a product backlog item, finish the whole thing a week more or later and then hand it over to the tester for testing on the last few days of the Sprint. What that programmer should do instead is develop just one small part of the product backlog item and then hand just that one part to the tester. Consider the case of the following User Story (US) which is about logging in:

US-1: "As a user, I can log in so that I have access to my data".

This user story can have detail added to it in the form of conditions of satisfaction which are really high-level acceptance tests for a user story. The Conditions of Satisfaction (CS) for our login story may include:

US-1-CS:

-The right credentials grant access.

-Can log in through Facebook.

-Wrong credentials display an error message.

-Can request a password reminder.

The programmer and tester get together and decide where to start. granting access when the right credentials are entered seems like a good place to start. So the programmer goes off and develops only that. While the programmer is coding, the tester is creating the test plans, test data, and automated tests. The testers will not be able to run these tests until the programmer says the code is ready and in some cases, the tester may have a hard time fully automating but in most cases for most applications, the tester can do a tremendous amount in advance of receiving final code from a programmer. When both the programmer and tester are done, they check their work into the official build system and tests are run. Then they talk about what to work on next. Let's say they choose Facebook integration again while the programmer develops the functionality, the tester creates, test plans, data, and automation scripts. There are still handoffs here. There are still moments when the programmer yells out, it is done. The tester can run the test but the handoff has been made very small and between each handoff, both team members are working on their parts of the feature.

• How DT can make a problem more visible?

Using a graph that illustrates the number of finished product backlog items per day of the Sprint can bring visibility and transparency. This graph should hang it on the wall near the team's task board or Sprint burndown chart. The axes are clearly labeled so it's not hard for the team to figure out what the chart is showing. If DT doesn't get the hint from the posted and updated graph (like the one on the right hand), Scrum Master should talk to them about it and ask them questions such as "How do you expect to finish eight product backlog items in two days when none have been finished so far?" or "Are there ways we can find together better so that we can start finishing some user stories earlier in the sprint?".

• How to practice the Swarming approach?

One thing that can help the team to work together in a better way is "Swarm". Swarming refers to having the entire team working on a single product backlog item at once. For most teams, this is never be permanently suggested, however, sometimes it can be great as a drill. 

The swarming technique is similar to closed fist swimming. You swim with your hands clenched in fists. this is clearly inefficient and you never want to race this way but it helps a swimmer learn to feel the water on the rest of their arm and the swimmer develops a better stroke because of it. So, swarming is not something to do permanently but great to try during the occasional sprint. When five to nine people work on a single product backlog item they will be forced to find new ways to collaborate. They will find ways to split the work into smaller parts, discover new ways to pair, and etc.

In conclusion, the above three methods help DT members work together on the subset of product backlog items, observing and tracking sprint progress and solving the problem of the programmers finishing work too late to fully test it.