Agile Teamwork: Three Ways to Minimize Handoffs

As an example, suppose a team is developing a new eCommerce application. The team chooses to work on this user story from its product backlog: “As a shopper, I can select how I want items shipped based on the actual costs of shipping to my address so that I can make the best decision.” At the beginning of the sprint, those who are interested in or who will be involved in developing this feature begin to discuss it. Let’s suppose this group includes the product owner, a business analyst, a tester, and a programmer. They begin by talking about some of the general requirements implicit in this feature: Which shipping companies (FedEx, DHL, etc.) do we support? Do we want to support overnight delivery? Two-day delivery? Three-day delivery?

As these discussions occur, the individuals involved naturally will begin thinking about how to get started. On a traditional project, each person would be able to start however he wanted (after the work was handed over). On a Scrum team, however, how to get started should be a collaborative discussion among those who will work on this feature. For this example, let’s assume that the programmer for some reason makes the case that it will be easier to start with FedEx. The tester agrees. The analyst states an intention to investigate DHL and learn more about the parameters that affect DHL shipping costs. The analyst’s goal is to have that information available by the time the programmer and tester finish with FedEx.

When the programmer knows enough to get started coding, she does so. The product owner, analyst, and tester discuss high-level tests (Will our site ship any odd-sized items like skis?). After that discussion, the tester turns the high-level list of tests into concrete tests (boxes of this size and weight going to that destination). The tester creates test data and automates the tests. Some automation may be possible without any interim deliverables from the programmer, while full automation may require getting an early version from the programmer. While the tester is thinking of the concrete tests, he also should inform the programmer of any test cases that she may not be considering while she’s programming.

When the programmer and tester have finished, they add support for calculating FedEx shipping costs into the build, complete with automated tests. Graphically, this can be depicted as shown in figure 1, where four individuals work together on one product backlog item rather than handing it off to each other.

Create a Manageable Mix
When planning a sprint, teams should pay attention to the sizes of the product backlog items to which they are committing. Some product backlog items are more complex than the FedEx/DHL example given. It’s possible that some product backlog items might require a week or more of programming before a programmer can provide a tester with something even initially testable. That’s OK. Not everything can be split as small as we might like. The key is to avoid bringing a bunch of items like this into the same sprint. Doing so will shift too much testing work to the end of the sprint. Instead of planning a sprint with, for example, three very large items that cannot be partially implemented, bring one or two such items into the sprint along with two or three smaller items. Some of the programmers can work on the large items, handing them over to testers whenever possible. The remaining programmers can work on the smaller items, ensuring a somewhat smoother flow of work to testers early in the sprint.