Specification by Example

Specification by Example by Gojko Adzic is a book that provides a set of process patterns that facilitate change in software products to ensure the right product is delivered effectively. This book about software requirements is based on the research of 30 teams that implemented 50 projects.

The first part of the book introduces the Specification by Example concept… with examples, showing what are the benefits of this approach. The second part presents the key process patterns. The final part of the book contains six case studies that explain how organizations changed their specification process according to their context and culture. The book is well written and easy to read. The key points are summarized at the end of each chapter and important points are highlighted in the text.

“Specification by Example” by Gojko Adzic is a very good practice-oriented book about requirements that I would recommend to every person involved in software development projects, either on the developer or the customer side. Its biggest strength is the continuous referral to actual situations experienced by the surveyed project teams. I don’t think that you can read more than two or three pages without getting some of this experience about getting the right software requirements. The result is a very good balance between concept discussion and practical experience.

Reference: “Specification by Example – How successful teams deliver the right software”, Gojko Adzic, Manning

Website: https://gojko.net/books/specification-by-example/

Quotes

Instead of blindly accepting software requirements as a solution to an unknown problem, successful teams derive scope from goals. They begin with a customer’s business goal. Then they collaborate to define the scope that will achieve that goal. The team works with the business users to determine the solution. The business users focus on communicating the intent of the desired feature and the value they expect to get out of it. This helps everyone understand what’s needed. The team can then suggest a solution that’s cheaper, faster, and easier to deliver or maintain than what the business users would come up with on their own.

Don’t make test automation the end goal. One of the most common early mistakes made by the teams I interviewed was setting functional test automation as the end goal of the process change. Business users generally think of functional test automation as something to do with testing and hence something they don’t need to get involved in. Unless developers understand that automated tests need to be human readable to improve communication, they’ll automate them in a way that minimizes development effort.

At the time of my interview, the uSwitch team was moving away from estimations. Estimates are useful when the business users don’t trust the development team or when they want to invest in larger pieces of work; now, neither scenario applies to uSwitch. The business users have a greater view of development and trust developers more than before. They also generally work on small increments. Estimating how long a piece of work is going to take isn’t necessary. At uSwitch, the average turnaround time for a feature – from the time it gets accepted for development until it goes live – is currently four days.