The book Executable Specifications with Scrum by Mario Cardinal starts with a strong statement: “This book aims to solve the recurring challenge encountered by many software development teams: They do not build the right software.” This is an ambitious goal, especially when you want to achieve it in a little bit more than 100 pages.
The structure of the book follows the requirements’ life cycle. It starts with the elicitation of the requirements, continue with their expression with user stories and ends with their confirmation with acceptance tests. Even if it provides a lot of valuable information, I am a little disappointed with this book, because it is neither a complete book on agile requirements as it focuses mainly on the user stories level and because it doesn’t explore enough on the xDD (Behavior Driven Development BDD, Acceptance Testing Driven Development ATDD) side to justify the executable title for me. Only two chapters (40 pages) on the total volume of the book are dedicated to scenarios and automated acceptance tests. This is however something that is also understandable because there are so many different tools available. The book will also have benefited from a use case that would have show the reader how to implement its concept in a practical example.
I would however recommend reading Executable Specifications with Scrum, because it provides an interesting and original point of view about agile requirements and user stories. The book is very easy and enjoyable to read and with a good level of details.
Reference: Executable Specifications with Scrum – A Practical Guide to Agile Requirements Discovery, Mario Cardinal, Addison-Wesley Professional
Quotes
It may seem odd to pair together the words “agile” and “specification.” And it may even seem odder to write a book specifically on this topic. For many people, a specification can be paired only with “traditional” document-centric engineering practices. In an agile context, where running software is the primary measure of progress, it is easy to believe that specifications are no longer a necessity. And yet specifications are still required—more than ever. Only the nature of what is produced is different. Specifications are not only briefer but also published in a format suitable for execution on a computer—hence the name executable specifications.
When you are confronted with many uncertainties, you must recognize your human limitations and accept that you can hardly expect to succeed in the first attempt. Several trials will be required. The only way to succeed is to fail. Therefore, fail early and often.
There is a lot of responsibility (both explicit and implicit) involved in managing the product backlog. Work will not get done without someone actively collaborating with stakeholders to understand customer/market needs and then communicating with the development team to ensure those needs are met. Being the product owner does not mean that he decides alone. The development team actively takes a hand in backlog management.
You must resist this temptation to mix acceptance tests with continuous integration. Because of hardware constraints, this can unduly slow down the code integration. CI feedbacks must be fast; otherwise, developers lose interest. Furthermore, developers are not required to check the evolution of the specifications as frequently as the code.
A common challenge when specifying software is how to assess the expected quality. Many stakeholders like to believe that quality is implicit and emerges without any special effort. Unfortunately, this is rarely the case.