Stories at scale – part 2

There is a part one to this series.

The format of a story

Ron Jeffries one of the founders of Extreme Programming (XP) created the concept of the three C’s. These are Card, Conversation and Confirmation.

  • Card
    A “Card” (or often a Post-It note), a physical token giving tangible and durable form to what would otherwise only be an abstraction. A story should be small enough to fit on a card.
  • Conversation
    A “conversation” taking place at different time and places during a project between the various people concerned by a given feature of a software product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation.
    The format of the actual story is a place holder for a conversation NOT a requirement.
  • Confirmation
    The “confirmation”, finally, the more formal the better, that the objectives the conversation revolved around have been reached.

The format of the story has developed from Ron’s three C’s with the help of Mike Cohn.
Mike developed the concept of As a, I want, so that. He gives an excellent discussion on why this format is a good one on his web site.


The acronym INVEST is a great way to check whether the stories are written well.

Acceptance Criteria

Acceptance criteria meet Ron’s third C: Confirmation and T in INVEST. We need a way of confirming that the story is complete.

Acceptance criteria can be written in the format of Given, When, Then.

The Given, When, Then format was created by Chris Matts as part of the work he was doing with Dan North on Behaviour Driven Development (BDD).

BDD gives us the ability to refactor our code in a similar way to unit testing but in a much less brittle way. BDD also allows us to take the unit test construct, which is developer led and not understandable to non-coders, and allow Product Owners to write tests and remove the hand-off step from PO to Developers.
This decreases the likelihood of misunderstanding and gives the POs a clear and measurable form of governance in determining the quality of the software they have commissioned.

This is achieved by automation and dashboard reporting as to the number of tests and how many have passed. This also gives a real-time progress report for stakeholders in how the team is progressing through the sprint. A huge selection of tools has sprung up from this language and plugging this automation together is now a trivial exercise.

As we move to scaling and addressing Agile governance, using a BDD construct becomes vital in ensuring quality at scale. Acceptance criteria can be written in this format by the PO to make BDD easier for the development team.

In terms of Real Options, BDD and TDD, gives us the option of refactoring code, which is essential for Agile delivery teams.

As Dean Leffingwell rightly says

‘You can’t scale crappy code’.

References to follow…

Coming next: Documentation, Modelling and Communication…

Leave a Comment

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