Specification By Example is an incredibly valuable addition to the Agile community. But what exactly is SBE and why is it needed?
Let’s start with the “why”.
Over the last 10 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 remembering that this is just the beginning).
However, one 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 percent 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 which features should be built. Don’t forget – every line of code you write costs four to five 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.
Specification by Example and Impact Mapping are immensely useful in helping us to 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 is Specification By Example?
Acceptance Test Driven Development (ATDD) and 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
Just 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 and 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 that the Product Owner actually wants. As a PO, having worked through such sessions with teams, I often find myself preventing developers' desires to develop more than what I actually need (in other words, 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.
We are really pleased to now offer 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 Edwin Dando for more information.