ISTOCKPHOTO

O
Accounting-Jane, and Jane was the VP of accounting. That
ur story so far... must be the right one. Right on page one it clearly said, Item
Tom Tester paged through the story profitability is the sum of selling prices for the SKU, divided
descriptions in the iteration backlog. by the sum of item cost, minus 100 percent. Paula closed the
The vendor report shall list vendors in file, thinking “That was easy,” without reading the section on
the order of percentage they met their page three: Special calculations for profitability of SKUs used
monthly sales quota. “What if the vendor as loss leaders. She was already programming. “For ‘sum of
hasn’t yet reported their monthly sales?” Tom wondered. “Or item cost,’ I can just multiply ‘current cost’ by the number of
what if it’s a provisional vendor that doesn’t have a set quota? items sold,” Paula thought. “I should be done with this story
We’ve got a few cases like that.” He turned to the next de- by this afternoon.”
scription: The sales manager shall be notified of all vendors Alan Analyst fretted over his notes. Sally Security Auditor
below 50 percent of quota. “Notified in what way? Isn’t the had been emphatic that customer details for medical device
vendor report a form of notification? How can I test this?” purchases be protected from easy access. Did these purchase
Sitting a few feet away, Paula Programmer began to imple- details also need to be encrypted in the database? Could they
ment the Item Profitability report. The profitability of each even do that and still provide the access needed by customer
SKU in inventory shall be calculated according to the SKU Ac- support when the customer called in for help? “I’d better
counting document on the accounting department fileserver. specify encryption; better safe than sorry. The programmers
She looked at the fileserver directory and saw a number of will come back and tell me if it can’t be done,” Alan thought.
files. SKU Accounting 2010, SKU Accounting 2011, SKU “I wonder when the security team will make the decision
Accounting-proposed, SKU Accounting-Jane, SKU Ac- as to which categories of products should be treated as ‘sensi-
counting-Harry. The one with the latest timestamp was SKU tive’? Perhaps I should just reference their specification docu-

24 BETTER SOFTWARE NOVEMBER/DECEMBER 2011 www.StickyMinds.com

ment. Surely they’ll have it finished soon.” Alan turned his people for each viewpoint will help reduce the number of im-
attention to the unanswered questions regarding marketing portant points missed.
tests. Don’t limit yourself to just three stakeholders, however.
Software development can be a tough and lonely business. Depending on the system being developed or the portion of
the system, you may find other stakeholders are essential to
The Three Amigos to the Rescue provide other points of view. Perhaps you have dedicated
One for all, and all for one. We’ll have a better shot at get- user experience experts who have deep understanding of how
ting the right system sooner if we collaborate. people use your system and how to avoid misuse. Or it may
The Three Amigos are the essential stakeholders of the be important to consider the needs of the systems operations
system being developed: The business (or product owner, in people who keep it running, or the customer service people
Scrum terms), the developer, and the tester. These three repre- who handle the calls from customers. Maybe the finance de-
sent the viewpoints of what the system is intended to do, what partment needs to provide information on tricky aspects of
can and cannot be implemented, and what might go wrong or fiscal control. Or the security team needs to ensure that the
be misunderstood. system is protected from malevolent users. Include these other
These three viewpoints represent orthogonal ways of viewpoints as needed. Just because this approach is called the
looking at the system, and I strongly recommend having at Three Amigos doesn’t mean it’s limited to three people. I’ve
least three people involved. It’s true that some people are often seen a “Three Amigos” consisting of four people.
good at seeing things from more than one of these viewpoints. On the other hand, don’t assume that more is better. Only
It’s tempting to theorize that you can get the same results with include people who have a stake in the success of the system.
fewer people. In actual practice, though, it’s hard to give mul- Many times there will be multiple programmers and testers
tiple viewpoints their due at the same time. Having different on the team. Don’t include all the developers and testers in

www.StickyMinds.com
NOVEMBER/DECEMBER 2011 BETTER SOFTWARE 25
 “ ... a well-functioning Three Amigos will continue the dialog
so that any misunderstandings will be
discovered and corrected early ... ”
each meeting, as that dilutes the sense of responsibility. With The goal is to come up with examples that cover all of the
that dilution, important points might be overlooked. At the important scenarios and to boil them down to the essence of
same time, the need for everyone to have his say will make the the functionality.
meetings drag on longer. You might have different developers During this meeting, take all the notes you find helpful or
and testers at different times, but only have one representative think might be helpful later. The important thing is to emerge
for each. Changing the individual participants from meeting with a complete but minimal set of examples to illustrate the
to meeting helps get everyone involved, gives everyone a functionality. These examples don’t need to be elaborate or
break, and keeps it fresh. detailed, but they do have to be clear enough that they com-
Getting the right people—and only the right people—in municate the intent of the functionality.
the room is always preferable for the best results.
Planning Meeting
How the Three Amigos Work Together When we get together to plan the next increment of devel-
The Three Amigos need to collaborate to define what opment work, such as the sprint planning meeting in Scrum,
needs to be done, how they’ll know when it’s done, and that the Three Amigos will use these examples to communicate the
it’s done correctly. After implementation, the Three Amigos intent to the full development team. The content of the ex-
need to review the work to make sure it’s still correct from amples will give the full team a reasonably good idea of what
everyone’s point of view. In between these two points, a well- will be involved to implement the user story. The number of
functioning Three Amigos will continue the dialog so that any those examples will give team members a good idea of its size.
misunderstandings will be discovered and corrected early, and If the story is split into multiple stories, the examples clearly
so any new insights can be incorporated to everyone’s advan- indicate which functionality is assigned to which story. This is
tage. Here’s how it might take place in a typical iterative- a big timesaver in my experience. I’ve seen team discussions
incremental agile lifecycle: go round and round, with some members thinking the story
is a small slice and others thinking it includes many other sce-
Backlog Grooming narios. If you’re estimating the size of stories, the explicit na-
Before development of a user story, generally sometime ture of the examples makes it much easier.
during the previous sprint or iteration, the Three Amigos sit “Doesn’t this take as long as if the entire team developed
down to discuss the upcoming work. We don’t want to wait the examples?” I hear this question a lot. No, the examples
too late to add details, because the delay will slow us down. communicate better than does more abstract text. If the ex-
We don't want to do this too far in advance of implementa- amples for a story don’t cover a particular situation, either
tion, because the details might get stale. that example describes another story or it’s new functionality.
Detailed knowledge imperceptibly deteriorates over time, Most of the time you’ll want to defer that new functionality
and the context changes such that the knowledge may no to give time for serious consideration. Make a note of the ex-
longer apply. As we learn new things in the process of doing ample, too. It’ll be a big help when you come back to it.
the work, it changes the way we think about the details of the
functionality we want. External events can also change what Development and Verification
we want the system to do. During development, the examples are turned into auto-
The clarification of the planned work is often called mated tests. The user story is not considered complete until
backlog grooming. Some teams delay discussing the details the examples pass.
until they start planning the next increment of work. When Turning the examples into automated tests should be a
this happens, I've generally seen the discussion of what the pretty easy chore, depending on how you’ve expressed those
work includes overwhelm the planning, resulting in a long examples and the tools you’re using. This is best done prior
session, indistinct acceptance criteria, and uncertain planning. to implementing the story, but might also be done as work
In one or more small group meetings, the Three Amigos begins on the story. Hooking the example up to drive the code
examine the planned stories one by one. Starting with the under development may have to wait until the story is a little
highest priority item, we examine each story, discussing it to further along. That’s OK. Just hook it up as soon as there’s an
gain a shared understanding of the intent. We flesh out that appropriate place to connect it. This work is often a collabo-
understanding by proposing examples: “Do you mean that ration between tester and programmer.
when _____ then _____?” “Yes, but if _____ happens then
_____.” We then look at these examples to determine what’s Exploratory Testing
an essential element for the desired functionality and what’s As each bit of functionality becomes available, you’ll want
an incidental detail required by the chosen implementation. to take a look at it. Does it fulfill the original intent of the

26 BETTER SOFTWARE NOVEMBER/DECEMBER 2011 www.StickyMinds.com

functionality? Does it seem reasonable? Does the function- Paula felt ready to get started on the new work. She had
ality still seem desirable when you see it in operation? Does examples that would clearly indicate when the software was
the system suggest unintended ways it might be used? If so, do behaving correctly, even when external data feeds were down.
these unintended operations work in a reasonable fashion and She relaxed knowing the start of the next iteration wouldn't
give correct answers? be wasted on merely trying to understand the requirements.
Passing the acceptance tests does not necessarily mean the Tom was relieved knowing that most of the end-of-itera-
software is acceptable. That’s just the first hurdle to accep- tion functional testing work was done. It would be a quick
tance. The example scenarios envisioned by the Three Amigos and straightforward job to put the examples they'd explored
before development should cover the expected functionality together into a form that could be run as an automated test.
pretty well, but no one has perfect foresight. It’s always best He was no longer bored at the beginning of the iteration and
to bring critical thinking to bear after development, also. under extreme pressure at the end when the final functionality
was completed. Instead, Tom now had time to do what he
Bringing It All Together considered the fun part of testing—looking for unusual be-
Paula, Tom, and Alan were wrapping up their backlog havior when the system had unexpected inputs. “Alan, when
grooming. Taking a digital photo of their work on the white- you've got some time, I'd like to show you something I discov-
board, Alan expressed his appreciation to his collaborators. ered today. The Product Category Profitability report screen
“Thanks for helping me build this list of unanswered ques- seems confusing to me when there are data gaps in both the
tions about the promotional offer feature. I'll take these over store results and the purchasing history feeds. Perhaps we can
to marketing to discuss them. If I can, I'll bring someone from make a simple change to clear it up, or maybe we should take
marketing to our next meeting. Until we get better clarity on it to the accounting department to define some future work in
this, we've got other important features to build. This one this area.”
isn't quite ready.” What a difference when we all collaborate! Software de-
Alan reflected on how much easier the process had become velopment is still hard, but not quite as hard as it was. And
since he no longer had to write all the details alone. Paula it's not nearly as lonely. {end}
was much better at math and could easily turn business de-
scriptions into algorithms on her own. Tom had devised some [email protected]
really interesting examples and, between the three of them,
they'd been able to agree on which results would be correct in
some unusual cases.

www.StickyMinds.com
NOVEMBER/DECEMBER 2011 BETTER SOFTWARE 27