How Specification by Example helps Agile teams make better products

Specification by Example is an incredibly valuable addition to the Agile community. Many people are talking about SBE, but what exactly is it and why is it needed?

Firstly, lets start with the why question.

Chaos ManifestoOver the last ten years, the Agile community has made huge inroads into improving how we build software.  In fact, we should be very proud of what we have achieved (while being mindful that this is just the beginning).

However, the area we haven’t addressed well is how to build the right product. I often describe a high performing Agile team as a Ferrari and the Product Ownership as the driver. Get the Product Ownership wrong and the team will go to the wrong place very quickly.

Even worse, we also know that 80-90% of the cost of a system (known as Total Cost of Ownership) occurs after the system goes live. Support, operations, maintenance and retirement are all operational costs that project-based staff often overlook when considering what features should be built. Don’t forget – every line of code you write costs 4-5 times more to support than it does to develop and test. The most cost effective code is no code at all as the Return on Investment is infinite. The answer is simple; write less code and only code that customers actually value.


Picture credit: from Specification by Example – Gojko Adzic

Specification by Example and Impact Mapping are immensely useful in helping us avoid the three undesirable quadrants above and focus on building stuff that customers actually care about. In the enduring words of the legendary Fred Brooks: “the hardest single part of building a software system is deciding precisely what to build.”

So what exactly is Specification by Example?  Acceptance Test Driven Development (ATDD) & Automated Acceptance Tests (AAT) help set clearer targets for development teams and are a drastic improvement of manual regression testing.

Behaviour Driven Development involves building a shared understanding between stakeholders and delivery teams through collaboration and clarification of specifications.

Specification by Example includes both these goals, plus living documentation.


Picture credit: from Specification by Example – Gojko Adzic

Picture2Just as Acceptance Criteria help refine a User Story, examples help refine (and automate) Acceptance Criteria.  Often this process helps flush out things we haven’t thought of, along with assumptions including things that we may have thought the Product Owner values when in fact they don’t.

The immediate benefits are:

  • Better communication –examples tend to improve discussion about the business problem among team members, reducing development time & re-work.
  • Gives a vision of the solution – examples allow us to start to form up a range of possible solutions.
  • Simple to understand – examples tend to be a lot easier to understand than specifications alone.
  • Reduces assumptions – working through examples as a team reduced assumptions about what the feature should do, but also what it is the Product Owner actually wants.  As a PO having worked through such sessions with Teams, I often find myself preventing developers desire to develop more than what I actually need (i.e. gold plating).
  • Can be automatically tested – obvious benefits here
  • Living documentation – the documentation is always up to date as it is derived from the examples and updated constantly by the continuous integration system.

The results we have achieved by helping teams adopt Specification by Example are significant and are something we are very proud of.  Our latest client to adopt SBE has just gone through Business Acceptance Testing with zero defects. In their own words, their average for BAT historically is around 100 defects.

We are really pleased to now be offering Agile teams our one-day Specification by Example workshop supported by professional coaching as part of our on-going mission to improve software quality. Please contact me at Assurity Consulting  for more details.


  1. Thanks for this nice sharing i think agile team can make better products through strong management. If they made their product according to customers demand then we can say that it is a better product. Customers play very important role in the success or failure of any product.

  2. I think it really comes down to the inivdidual employee. Good developers find ways to be more effective with each other. They find nooks and crannies to work together. They relocate temporarily and work in each other’s cubes if there is room. If they work at home, they use video-conferencing tools and instant messaging to make their presence nearly real-time. But, for the average employee, I think being removed from the rest of your team can fail miserably. Those employees may lack the desire to do what is best for the project or may not have the personal drive and desire to see the project succeed. If you can find the right people, then you can have a successful distributed team.

%d bloggers like this: