Executable Specifications with Scrum: A Practical Guide to Agile Requirements Discovery Book Review

This book is exactly what the sub-title "A Practical Guide to Agile Requirements Discovery" says it is. The book is a very detailed breakdown of the steps that should be taken by Scrum teams that want to succeed. I have listed the chapters below to give you an overview of the topics the author covers in this book. Chapter 1. Solving the Right Problem Chapter 2. Relying on a Stable Foundation Chapter 3. Discovering Through Short Feedback Loops and Stakeholders’ Decrements Chapter 4. Expressing Desirements with User Stories Chapter 5. Refining User Stories by Grooming the Product Backlog Chapter 6. Confirming User Stories with Scenarios Chapter 7. Automating Confirmation with Acceptance Tests Chapter 8. Addressing Nonfunctional Requirements Chapter 9. Conclusion In the first chapter the author covers how the scrum teams can distinguish requirements from the solution. In other words the what from the hows. In the second chapter the author shows how to develop guardrails which are basically the artifacts and activities that will keep the project within its defined scope. The examples that the author uses are a healthy team, involvement of all stakeholders, a shared vision, a meaningful common goal, a set of high-level features, and "can-exist" assumption. In chapter 3 the author really drives home applying the trial and error method for discovering desirements through short feedback loops. In chapter 4, Expressing Desirements with User Stories, the author does a great job of showing how to create user stories. He does a great job of breaking down the structure of the user story and introducing the questions that you ask when creating them- who, what, and why, questions. The author also touches on the importance of establishing Ubiquitous Language. Ubiquitous Language is a shared team language that defines a certain domain. Chapter 6 also touches on Ubiquitous Language. He ends the chapter by introducing how to use a product backlog to record desirements. The next chapter, Refining User Stories by Grooming the Product Backlog, is all about roles and activities that need to be in place in order to managing the product backlog correctly. Topics include Managing the Product Backlog, Collaborating to Groom the Product Backlog, Ranking User Stories with a Dot Voting Method, Illustrating User Stories with Storyboards, Sizing User Stories Using Comparison, Splitting User Stories Along Business Values, Tracking User Stories with a Collaboration Board, and Delivering a Coherent Set of User Stories. Chapter 6 is all about confirming your User Stories by scripting scenarios that validate them. The author also introduces two tools for automating validation. He introduces the Framework for Integrated Test (FIT) and the Given-When-Then syntax the Behavior-Driven Development (BDD) community uses. He also touches on Ubiquitous Language again and its importance. Chapter 7 is all about automating confirmation, which is done by turning scenarios into acceptance tests. This chapter explains how to make the scenarios “executable” by a computer. The author introduces existing BDD automation frameworks which include Cucumber for Ruby, JBehave for Java, and SpecFlow for Microsoft .NET. I downloaded SpecFlow which is a solid framework backed up by very thorough documentation. The last chapter before the concluding chapter covers Nonfunctional Requirements (Quality Attributes). Quality attributes are all about tradeoffs and constraints. The author does a great job of explaining quality attributes, showing how they are broken down into internal and external categories, and then applied through constraints (which he calls restrictions). The two things I like most about this book was the flow of the chapters and the author's recognition of the importance of architecture. The chapters build on each other so I definitely recommend a cover to cover read of the book. The author has a great writing style, so that is easy to do. When the author spells out what roles make up a team he includes architects. He defines architects as members of the development team who are responsible for designing the structural foundation upon which the solution is built. Their role is to ensure the development team builds the software right and delivers quality work. I have seen a lot of confusion in Scrum teams when it comes to architecture, because a lot of the Scrum material out there today discounts it. All in all I found this book a very enjoyable read. If you are involved with agile development teams, you should definitely read this book. The elicitation of requirements is really lacking in most of the agile teams I encounter. This book can help to remedy that.

Executable Specifications with Scrum: A Practical Guide to Agile Requirements Discovery