I recently had the pleasure to attend Gojko Adzic’s “Specification by Example: From User Stories to Acceptance Test" training course … taught by Gojko himself! Having read his brilliant books: “Bridging the Communication Gap” and “Specification by Example. How successful teams deliver the right Software”, I was very excited to get the chance to discuss my experiences of applying spec-by-example with the man himself. My goals for the course were as follows:
I'm glad to say that the course did not disappoint! Here is what I learned.
Before attending Gojko's course, I believed it was impossible to run a session without showing boring PowerPoint presentations, but he managed to avoid them! In fact, his course is a 2-day hands-on experience which is a very effective way to show what you can get by Specification By Example (SBE) and when to use it.
To get us across those essential concepts, Gojko has created two collaborative exercises, which aim to simulate what happens when there is a lack of domain knowledge and the team is under time pressure. These are two typical situations in larger organisations when the team is working on a system that is a piece of a larger puzzle that nobody fully understands.
Thanks to the collaborative exercises, we went beyond the theory explained in the books, and we learnt how to write good specifications by experiencing how to run and facilitate a Specification By Example Workshop. We learnt how to discover the right questions to ask by collaboratively visualising team's and stakeholders' understanding through real examples. Here are few guidelines to follow:
These concepts are an essential understanding of how to elicit requirements and write better specifications.
As Gojko writes in “Bridging the Communication Gap”:
In order to get the most out of acceptance tests, we need to distill what should be done from the discussion and not really focus on how it is going to work.
When people mix up the “WHAT” and the "HOW" they create specifications that are difficult to read for business people. It is common to get specifications that include lines of code. That must be avoided because acceptance tests are a deliverable that needs to be written by business people together with developers and testers to ensure a common understanding of what needs to be built so that we can meet client's expectations. "HOW" should also be kept separate from the "WHAT" as the Acceptance tests are Living Documentation: the examples are the only executable part of the test, and they should clearly show the relationship between the inputs and the outputs otherwise they can't be automated. If we include unnecessary details, the specification becomes impossible to maintain, change, and execute and will go out of date very quickly.
In just 2 days, I learned more than I could imagine from Gojko's course. In addition to the concepts outlined above, it was extremely useful to see how he facilitates an SBE Workshop. A good facilitator is essential to involve people in the discussion and end the session achieving the most important goal: build the right product and improve its quality, by encouraging the collaboration between the delivery team, business people and users. This ensures a shared understanding of the reason why we are building a product, which leads to writing better requirements from the start of the developing cycle.
P.S I'd like to thank my classmates, for their willingness to share experience and knowledge :-)
Software is our passion.
We are software craftspeople. We build well-crafted software for our clients, we help developers to get better at their craft through training, coaching and mentoring, and we help companies get better at delivering software.