ISTOCKPHOTO

T
eams using a sequential development process which may or may not be anything like what they really want.
have become accustomed to handoffs between As such, Scrum teams forego a lengthy, up-front requirements
specialists. Analysts hand their work to designers, phase and the resulting product specification in favor of a dy-
who hand it to programmers, who pass it on to namic product backlog.
testers. Teams that are new to Scrum often do not go far Because Scrum teams shift focus from writing about re-
enough in eliminating these handoffs, wrongly assuming, for quirements to talking about them, conversations with the
instance, that the programmers should finish programming a product owner—rather than a product spec—become the pri-
product backlog item before handing it off to the testers or mary way of finding out how a new feature should behave.
that analysts should work at least one sprint ahead of the rest Team members talk with the product owner about how a
of the team. feature should work, how quickly it should perform, what
High-performing Scrum teams, however, have learned to acceptance criteria must be passed, and so on. Scrum team
do a little bit of everything all the time during a sprint, thereby members also talk with users, customers, and other stake-
eliminating large handoffs. To do this effectively, teams must holders as appropriate and, perhaps most importantly, with
make three changes: favor talking over writing, make hand- each other.
offs very small and very often, and mix the size of items that On traditional projects, analysts often act as intermediaries,
are brought into each sprint. communicating customer needs to programmers. On Scrum
teams, however, analysts function as facilitators, ensuring that
Stop Writing and Start Talking appropriate discussions between team and product owner
There’s a grand myth about requirements: If you write take place. For instance, an analyst might steer the product
them down, users will get exactly what they want. That’s not owner and team toward talking about a particular user story
true. At best, users will get exactly what was written down, because it has more risk than another of going astray. At other

32 BETTER SOFTWARE MARCH/APRIL 2010 www.StickyMinds.com

times, an analyst might convey a top-level understanding of a amount of work being transferred from one person to the
new feature to the team before bringing the team and product next should generally be as small as possible.
owner together to discuss the details. In all cases, analysts on As an example, suppose a team is developing a new eCom-
Scrum teams foster communication rather than distill infor- merce application. The team chooses to work on this user
mation through a document. story from its product backlog: “As a shopper, I can select
All of this is not to say we should abandon written require- how I want items shipped based on the actual costs of ship-
ments documents. Rather, we should use documents where ping to my address so that I can make the best decision.” At
appropriate. Experienced Scrum teams lean heavily on cleanly the beginning of the sprint, those who are interested in or
written code and automated test cases. They then augment who will be involved in developing this feature begin to dis-
these forms of documentation with a written requirements cuss it. Let’s suppose this group includes the product owner,
document only to the extent that such a document is helpful a business analyst, a tester, and a programmer. They begin by
or required for regulatory, contractual, or legal purposes. As talking about some of the general requirements implicit in this
Tom Poppendieck, coauthor of books on lean software devel- feature: Which shipping companies (FedEx, DHL, etc.) do we
opment, once told me, “When documents are mostly to en- support? Do we want to support overnight delivery? Two-day
able handoffs, they are evil. When they capture a record of a delivery? Three-day delivery?
conversation that is best not forgotten, they are valuable.” As these discussions occur, the individuals involved naturally
will begin thinking about how to get started. On a traditional
Transfer Small Tasks Frequently project, each person would be able to start however he wanted
On Scrum teams, the unit of transfer between disciplines (after the work was handed over). On a Scrum team, however,
should be smaller than an individual product backlog item. how to get started should be a collaborative discussion among
That is, although there will always be some handoffs, the those who will work on this feature. For this example, let’s

www.StickyMinds.com MARCH/APRIL 2010 BETTER SOFTWARE 33

 “A symptom of continuing to hand off work in overly large chunks is a tendency
for no product backlog items to be finished until the last few days of the sprint.”
assume that the programmer for some reason makes the case expected to test everything that quickly. The best way to ex-
that it will be easier to start with FedEx. The tester agrees. The pose this problem is to create a chart of the number of product
analyst states an intention to investigate DHL and learn more backlog items finished as of each day in the sprint. An example
about the parameters that affect DHL shipping costs. The ana- can be seen in figure 2a. As the ScrumMaster on a team, I
lyst’s goal is to have that information available by the time the often just hang this chart in the team area with no fanfare
programmer and tester finish with FedEx. or explanation. Team members soon figure out the problem
When the programmer knows enough to get started exposed by a chart like this and, hopefully, start to find ways
coding, she does so. The product owner, analyst, and tester to finish product backlog items sooner. The result often will
discuss high-level tests (Will our site ship any odd-sized items be similar to figure 2b, which shows a much smoother flow
like skis?). After that discussion, the tester turns the high-level through the sprint.
list of tests into concrete tests (boxes of this size and weight
going to that destination). The tester creates test data and au-
tomates the tests. Some automation may be possible without
any interim deliverables from the programmer, while full au-
tomation may require getting an early version from the pro-
grammer. 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 de-
picted as shown in figure 1, where four individuals work to- Figure 2

gether 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 commit-
ting. 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 program-
ming before a programmer can provide a tester with some-
thing 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
Figure 1
smaller items. Some of the programmers can work on the
large items, handing them over to testers whenever possible.
Next, the programmer and tester check in with the business The remaining programmers can work on the smaller items,
analyst, who hopefully has learned more about calculating ensuring a somewhat smoother flow of work to testers early
DHL shipping costs. The process is repeated, and support for in the sprint.
DHL shipping calculations is added to the application when Creating the right sense of teamwork can be challenging.
the programming and testing are complete. The key element ScrumMasters can help by ensuring that the team embraces
in figure 1 is that the team has learned to work by doing a the concept of whole-team responsibility and whole-team
little of everything all the time. Rather than an analysis phase commitment to deliver working software at the end of each
(done without the programmer and tester) followed by a pro- sprint. Though the team might struggle at first to break long-
gramming phase followed by a testing phase, a little of each held habits of specialization and handoffs, increasing commu-
of those activities is happening at all times. nication, decreasing the size of handoffs, and mixing the size
A symptom of continuing to hand off work in overly large of backlog items brought into a sprint will help individuals
chunks is a tendency for no product backlog items to be fin- make the shift from sequential development to working as a
ished until the last few days of the sprint. Testers on teams team. {end}
that work this way often complain that they are given nothing [email protected]
to test until two days before the end of a sprint and then are

34 BETTER SOFTWARE MARCH/APRIL 2010 www.StickyMinds.com