# Term Possible Association
1 ATDD Bad
2 Backlog Coordinate
3 Daily Standup / Daily Scrum Design
4 Product Owner Facilitate Collaboration
5 ScrumMaster Iteration
6 Sprint Specify
7 TDD To Do List
8 WIP Tradeoff

We are about to play word association game.  This is a game, not a test, so the purpose is to provoke thought, not define the exact meaning of each term.

Given the list of the words on the left, find the most appropriate match on the right. Remember that this is a game, so, even though both “ATDD” and “TDD” are listed on the left, you won’t find “Testing” anywhere on the right. If it were that easy, it wouldn’t be fun or informative!

The Associations
ATDD = Specify

Oh, you thought ATDD / Acceptance Test Driven Development was about testing.

In fact, ATDD is at least as much about specification as it is about testing. With ATDD, Product Owners, Business Analysts, Testers, Developers and other stakeholders use a common language to concretely define examples that specify the expected behavior of a system.

The concrete examples are created before the code, and when specified in a format compatible with one or more testing frameworks, like Fit or Cucumber, they can serve as executable specifications (once the supporting fixtures are coded).

With ATDD, external dependencies are often mocked or stubbed, making it possible to verify that functionality meets the specifications, but not necessarily proving that the system works in an end to end fashion. As such, despite its’ name, ATDD does not replace integration testing, but it sure does make it a whole lot easier to specify expected behavior in a way that can truly be understood by all, hence, ATDD = Specify.

Backlog = To Do List

At its’ simplest, your Product Backlog is a prioritized To-Do List with estimates. Your Iteration Backlog is your short term to do list. Doesn’t sound very technical, but that’s what they are.

Daily Standup / Daily Scrum = Coordinate

Traditional project teams focus their status meetings on providing information to the manager, who then makes all of the decisions.  Agile teams answers three questions so that team members can commit to each other and self manage.  The questions are:

  1. What did I do since the last stand-up?
  2. What will I do before the next standup?
  3. What blockers do I have?

You should answer these questions succinctly,  deferring details until the post meetings (which I call the “Daily Sit-Downs”) so that just the information necessary for the team to coordinate, and hence, self manage, is covered.

Product Owner = Trade-offs

We all know that the key responsibility of the Product Owner is maximizing the business value of the system that is developed.  But, how much fun would it be if “business value” was on the list?

More importantly, when I think about how the Product Owner maximizes values, I think of at least two key things, conveying the information that the team needs, and making trade-offs decisions.  I emphasize the trade-off decisions in this post, as in my experience, this aspect of the Product Owner role is sometimes not given enough emphasis, so, at least for this post, Product Owner = Trade-offs.

ScrumMaster = Facilitate Collaboration

There are many attributes of the ScrumMaster role.  At the core, the ScrumMaster ensures that the process is being followed.  So, I guess I could have said, ScrumMaster = Ensure Process is Followed, but, remember this is a game, not a test, so I want you to think.

In thinking about the ScrumMaster role, my experience has shown that it is easier for novice ScrumMaster’s to grasp the process, but far more difficult to understand how to facilitate the self managing aspects of the team.

As such, in this post, ScrumMaster = Facilitate Collaboration.


Sprint = Iteration

A textbook definition of sprint (outside the world of agile), as given by Wikipedia is a type of short race in athletics.

When I co-train with Sanjiv Augustine he likes to point out that racing is not an appropriate metaphor for executing with a sustainable pace.  I agree, and I prefer Iteration to Sprint.

TDD = Design

TDD, or Test Driven Development, is an approach where a developer, or pair, write a test prior to writing just enough code to pass the test. The tests are automated, and they are constantly run, to ensure that code changes work and that they don’t have unintended consequences.

OK, you may ask, then why do I equate TDD with design?  As with ATDD, TDD much more than testing.

Most hard core devotees of TDD will tell you that the act of writing the test prior to writing the code is an easy and cost effective way to create simple, clean, loosely coupled, highly cohesive, i.e., well designed, code.

Hence, TDD = Design!


WIP = Bad

Work in Process, a.k.a. WIP, is the partially completed deliverables. There will also be some unfinished work in a system, but complexity quickly expands as the amount of WIP increases, so, WIP = Bad.

Answer Key Summary

# Term Association
1 ATDD Specify
2 Backlog To Do List
3 Daily Standup / Daily Scrum Co-ordinate
4 Product Owner Tradeoffs
5 ScrumMaster Facilitate Collaboration
6 Sprint Iteration
7 TDD Design
8 WIP Bad


There are many equally valid, and in fact more valid associations than the ones I listed, but this was a game, not a test, with the intent of provoking us to thinkPlease feel free to provoke me, and all readers of this blog by providing your feedback.