Customer Obsessed Engineering

Customer Obsessed Engineering

3.7 Elaboration

Elaboration takes your specifications from skeleton to sprint-ready, fully fleshed out across every layer at which the system is tested — and live-linked to the engineering models that prove them out.

Zac Beckman
Apr 28, 2026
∙ Paid

In 3.6 Specification we worked through the first two stages of Behavior Driven Development — Discovery and Formulation. We surfaced scenarios in three-amigos conversations and shaped them into Gherkin “Given-When-Then” statements. That gave us the outline of every feature in our product increment.

Elaboration is where we move from outline to depth.

A very important takeaway from chapter 3.6 bears repeating here, because the entire purpose of this activity hangs on it:

The specifications you write now are living documents. They will evolve, change and be added to. That’s why it’s so important to create a live link to the implementation — the code that will validate the specifications. As the specifications change that live link will preserve our value chain from customer desires to delivered code.

Hold on to that idea. Elaboration isn’t about freezing requirements before the team writes a single line of code. It’s about building the connections — between the spec and the marble, between the marble and the test, between the test and the production code — that let the spec keep evolving without the value chain ever going slack.

Introduction

This activity has three jobs.

First, we expand each scenario across the levels at which the system is tested: component and assembly. A login feature has UX scenarios about what the customer sees and experiences. It also has assembly scenarios about which events fire, which commands route through which aggregates and what payload comes back. Both layers need specifications. Both layers need to be testable. Skipping a layer means leaving a gap through which defects love to slip.

Second, we create a live link between every specification and the engineering model that implements it. Each Gherkin feature points back to a marble. Each marble points forward to a Gherkin feature. That bi-directional link is what makes our specifications living documents — when the spec changes, the marble updates with it, and vice versa.1

User's avatar

Continue reading this post for free, courtesy of Zac Beckman.

Or purchase a paid subscription.
© 2026 Boss Logic, Inc. · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture