Specification by Example by Gojko Adzic

Specification by Example - How successful teams deliver the right software

Specification by Example is a set of process patterns that facilitate change in software products to ensure the right product is delivered effectively. This book written by Gojko Adzic 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 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 material. 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: http://www.specificationbyexample.com/

Specification by Example - How successful teams deliver the right software

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.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Requirements Management Resources
Resources

International Institute of Business Analysis (IIBA)

The International Institute of Business Analysis (IIBA) is an independent non-profit professional association for business analyst. IIBA was established in 2003 as a Canadian Corporation. Its mission is to develop and maintain standards for the practice of business analysis and for the certification of its practitioners. IIBA local chapters exist in many cities in Canada, […]

Read More
Requirements Management Resources
Resources

How to Split User Stories

George Dinwiddie proposes a list of material that should help you in the task of splitting user stories used to manage requirements in Agile approaches. In his own handout, he explains the difference between stories in the backlog that are often called features or epics and stories selected for development that should generally be small […]

Read More
Requirements Management Resources
Resources

Use Cases Definition by Usability.gov

Usability.gov is the primary government source for information on usability and user-centered design. The web site has a page dedicated to use cases that explains what they are and how to use them.

Read More

Copyright © 2009-2021 Martinig & Associates