Lessons learned from the Specification by Example workshop

By | February 14, 2014

For two days in the beginning of this week I have been on the Specification by Example workshop held by Gojko Adzic (@gojkoadzic). I can recommend the workshop for everybody interesting in Specification by Example.

We were ask to write down what we learned during the workshop so here is my notes and my takeaways from the workshop.

Day 1

Workshop 20 min


  1. Self organising teams
  2. The leaders of the workshop is the business users

Development can be in flow chart, lists, pseudo code or even SQL.

Develop a blackjack dealer from the requirements given. This lead to a lot of discussions about the requirements and even finding out that the requirements was wrong in some sense. This was done by discussing way the expectations was different between the groups.

It’s difficult to ask god questions, especially on the question, “Do you have any questions?”. One good question to ask is what is going to be tested. But how do we come up with good questions under time pressure?

We need to tighten the feedback loop, usually when we have developers that write the code and testers that test the written code later on, the feedback loop is too long. Also test have the problem that we have fewer testers then developer so that because the bottleneck of the process. Testing the code may spill over to the next iteration and when (not if) the find bugs, we are usually in the next iteration. Hence taking time from the next iteration with things that was marked as “done” in the previous one. So we have a hidden cost from that test starts to it is finished. This leads to process bankruptcy where we have to have a “clean-up sprint”, to clean up things that are not really finished.

We need to change the process so that the testers do not need to test everything at the end and tighten the feedback loop for the developers.



  • Implementation
  • Understanding
  • Scope
  • Tests
  • Assumptions
  • Requirements

Get feedback early. Let testers make examples (green arrows)  instead of testing the software (black arrows). Developers can then test it on its own. They usually automate the tests in some way when they are forced to run the test to see if the examples are fulfilled.

Tester role change

Death by Examples

There are one thing to lookout for when writing examples and that is Death by Examples.

Death by Examples is when the team spends hours on the details of the example. People adding lots of examples because they think that the domain is more complex then it necessarily is. Try to abstract things to make it easier to understand and this will also give you new concepts to talk about.

Facilitating a specification workshop

For a facilitator, think about the following:

  • At least 2 groups
  • Look for difference in the results
  • Look for different level of  information
  • Compare the models with each other
  • Discuss the scratch-out by asking “why did you scratch that out?”
  • Define the scope
  • Don’t skip the obvious, if it seems obvious, discuss it in 5 min, if everybody still think it’s obvious then it probably is.
  • Listen to different opinions, there i no right or wrong here
  • Make people talk – ask them leading questions

There are two different scopes when doing specification by example.

  • One High Level that is good for planning
  • One Low Level that is good for implementation

Key process pattern

Workshop on specification quality


Tying to rate the quality of different specifications by the

  • Level of information
  • Structure

We should set points based on the following criterias

  • Shared understanding
  • Tests
  • Documentation

A good technique to refining a specification with high detail is to try summarize the specification without losing precision. This reviles informations that is unnecessary to have in the example, still the information may be needed in the automation layer later but remove it from the examples.

Agile Testing Quadrant

Agile Testing Quadrant

Day 2

Recap from yesterday:

  • Visualize the problem
  • Make people to change them self by asking them to do experiments
  • Waste snake, post-its with wastes
    • Kick-starts the retrospective
  • Measure the amount of questions that come up during development
  • Measure the amount of boomerangs
  • Better specification workshops
  • Use flow based requirements as scope
    • Work with the users to make user stories
    • User story mapping

Story mapping

  • Specification workshop, time-box the it in 5-15 min
  • Don’t bother automating tests on simple tasks

Impact mapping

Deriving scope from goals (Hierarchical backlog technique)

  • Way? (Goal)
  • Who? (Users, stakeholders, actors)
  • How? (Behavioural change => faster, better, cheaper)
  • What? (Deliverables, Solutions)

Group stories on impact to help prioritising them

Impact mapping

Refining a specification

  1. What are the examples?
    1. Output first
    2. Which inputs generates these outputs
    3. Play with the inputs (Boundaries)
  2. Descriptions / Title

Arrangement of tests in the living documentation

  • Long term specifications based on features, use cases.
  • In the current iteration by user story
  • Tests that fails, but are to hard to fix at the moment

Spec organisation

Mixed Q/A

Q: Geography distributed, how to do a specification workshop?
A: Prepare some user stories with Tree Amigos before meeting with the whole group. This will be like a mini specification workshoop. Tree Amigos is a small group of three with one person from business, one from test and one from development.

Q: Large flow-based requirements in word, how to convert them into specification by example?
A: Save the requirement as HTML and use Concordion or copy and past it into a tool like FitNesse. Add example for the different steps (as new pages) and automate it.

User group/Mailing list

Google mailing list, Specification by Example.


Clean Language
Agile testing quadrant
Effect Mapping
ExploreIt – Elisabeth Hendrickson
Exploratory Software Testing – James Whittaker
How Google Test Software – James Whittaker


Michel Bolton

Collected some links here:

Tools and Frameworks



One thought on “Lessons learned from the Specification by Example workshop

  1. Pingback: Specification By Example with Gojko Adzic | Aidium

Leave a Reply

Your email address will not be published. Required fields are marked *