If you read a card and say, “OK, I completely understand that,” you just go off and work, and you could have made a million and one assumptions. If you read a card and there is enough of “I’m not quite sure,” it pushes you to have a conversation, drawing it out at the start of an iteration, and then talking about different implementations and their effects. The testers would then consider how this impacts tests. BAs could think about what’s also coming up soon and see how that its in. “Just enough” means that your developer, BA, and QA are standing against a board and really discussing how this needs to work.

Whether you decide to have someone work one week ahead to prepare initial examples or hold an introductory meeting to identify open questions, remember that the goal is to prepare for the discussion later, not replace it.

Choosing a collaboration model

I don’t think there’s a one-size-its-all heuristic that will help you choose the best model for your team, including the balance between individual up-front work and more handson collaboration. After comparing the teams who had similar processes, I suggest basing your decision on the following criteria:

•How mature is the product?

•How much domain knowledge is there in the team?

•How much analysis do typical changes require?

•How close are the business users to the development team? Are they readily available to discuss and verify examples?

•Where’s the bottleneck in the process?

Immature products require big workshops and lots of up-front analysis. With immature products, it’s important to get testers and developers to contribute to speciications more actively, because the underlying system is changing frequently and they have insights that the business users won’t have.

Mature products might allow for less analysis up front and other models of collaboration. A mature product probably means that there will be few surprises. Business analysts and product owners most likely have a good idea of what the technology can give them, and they can do a good job of preparing examples up front.

If the team is relatively new or if testers and developers don’t have a solid understanding of the business domain, it’s worth running big workshops. All-hands workshops are a great way to eficiently transfer the knowledge about the business domain to the entire team. Once the team understands the business domain better, smaller and more focused discussions might be suficient.

94 Specification by Example

If typical changes require a lot of analysis, then someone in an analyst role should work ahead of the team to prepare detailed examples with stakeholders. Otherwise, any discussion during the workshops will end quickly and with too many open questions. If relatively small and well-understood features normally come into development, preparing some basic examples up front to make the discussion run more smoothly might be suficient.

Teams with remote business users typically have to do more work up front than those with business users who are readily available to answer open questions. If the business users aren’t available for speciication workshops at all, most questions and functional gaps have to be identiied and addressed up front.

Finally, there’s no point in overloading team members who are already a bottleneck in the process. The teams where testing is a bottleneck should get developers and business analysts much more engaged in up-front work. Likewise, the teams where business analysts or subject matter experts are the bottleneck should get testers to help with upfront analysis.

Remember

•Speciication by Example relies heavily on collaboration between business users and delivery team members.

•Everyone on the delivery team shares the responsibility for the right speciications. Programmers and testers have to offer input about the technical implementation and the validation aspects.

•Most teams collaborate on speciications in two phases: Someone works up front to prepare initial examples for a feature, and then those who have a stake in the feature discuss it, adding examples to clarify or complete the speciication.

•The balance between the work done in preparation and the work done during collaboration depends on several factors: the maturity of the product, the level of domain knowledge in the delivery team, typical change request complexity, process bottlenecks, and availability of business users.

96 Speciication by Example

unit all correct products are displayed”). Finding out that something important was missinghalfwaythroughaniterationwouldseriouslydisrupttheoutput.Oneiterationendedwithcustomerssayingthattheteamdeliveredsomethingcompletelydifferentfromwhat was expected. The last week of each iteration was reserved for the model ofice: effectively, an iteration demonstration. Ferrero traveled to the United States for one model ofice and worked with business analysts on illustrating requirements with examples for two days. As a result, the team committed to 20% less work for the next iteration and delivered what they promised.

“The feeling in the team was also much better,” said Ferrero. “Before that, [the developers] were working with a feeling that they were making it up as they go, and had to wait for feedback from business analysts.” According to Ferrero, the amount of rework dropped signiicantly after they started illustrating requirements using examples.

Ferrero’s wasn’t the only team to experience results like these. Almost all the teams proiled in this book conirmed that illustrating requirements using examples is a much more effective technique than specifying with abstract statements. Because examples are concrete and unambiguous, they’re an ideal tool for making requirements precise—this is why we use them to clarify meaning in everyday communication.

In Exploring Requirements,1 Gerald Weinberg and Donald Gause write that one of the best ways to check if requirements are complete is to try designing black-box test cases against them. If we don’t have enough information to design good test cases, we deinitely don’t have enough information to build the system. Illustrating requirements using examples is a way to specify how we expect the system to work with enough detail that we can check that assertion. Examples used to illustrate requirements are good black-box tests.

From my experience, it takes far less time to illustrate requirements with examples than to implement them. Concluding that we don’t have enough information to illustrate something with examples takes far less time than coming to the same realization after trying to implement the software. Instead of starting to develop an incomplete story only to see it blow up in the middle of an iteration, we can lush such problems out during the collaboration on speciications while we can still address them—and when the business users are still available.

In May 2009 I ran a three-hour workshop on Speciication by Example2 during the Progressive .NET tutorials. Around 50 people, mostly software developers and testers, participated in this workshop. We simulated a common situation: A customer directs the team to a competitor site and asks them to copy some functionality.