Stories and the Three C's - Revisited Yet Again

This article is based on some notes to a member of the Agile Mentoring Slack group. They found themselves in a situation where a lot of attention and time were being spent on “writing stories”, to the point where sometimes the team would build something or fix a bug, and then working for a long time with the Product Owner to get the story written right. Sometimes getting the story “right” and into the backlog took longer than doing the work – which was already done.

To really know why that’s happening, one would have to be there, observe things, ask questions, talk with people in groups and singly, and so on. We can readily speculate about common reasons why there is a focus on written stories. We’d try not to believe these, but we’d be alert to them:

Credit

Maybe there is some kind of special credit for getting a story done and maybe the more complicated it looks, the more credit you get.

Blame

Maybe there is blame when things don’t get done, so there is value to putting things in the Backlog that are guaranteed to be done because they already are.

Time

Maybe they’re trying to do too much design and detailed planning in Sprint Planning, so they hope that better written stories will keep that meeting in the time box.

There are other possibilities, and we could break these down into sub-genres, but for our purposes, we have no need – and no real information. What we would actually do would depend on the real reasons somewhat, but let’s talk about what I’d want to do, and why.

Long ago, the first XP team described a story as having three parts. Today I’d say those are:

Card

A literal card saying briefly what the story is. A name will suffice: “Accept Visa Cards”. If there isn’t room on the card for your story, you are required to use a smaller card.

Conversation

The whole team, devs, BAs, testers, Product Owner, or at least a solid delegation from each area, talk about the problem being solved. This typically starts with the Product Owner saying “We need to accept Visa cards”. The whole group talks about what that means, provides the information they have about how Visa works, how it may differ from MasterCard, how the system works, and so on. As a story’s Conversation goes forward, the group focuses more and more on creating Confirmation Examples.

Confirmation Examples

These are concrete examples, with names and values plugged in, a situation fully described. “Joe Smith, Visa 1234-…, attempts to charge $21.39. He is at his credit limit. The system displays ‘No go, Joe’”. For best results, the Confirmation Examples are expressed as actual executable tests (called “checks” by some). These tests exercise the actual system and report whether the expected result comes out or not. If it does, good. If not, the story isn’t done yet.

Let’s compare the two cases.

In the old situation, we’ve spent a long time refining words on a very large card (or big text field in Jira), and not much time really talking about what those words mean. Whoever wrote them couldn’t possibly write down everything they knew, may even have made rerors or misteaks, or forgotten some important.¹ Whoever reads them can’t remember everything, may misunderstand some of it, may be left wondering about three things and one that they forgot. This is what we call the “power of the written word”.

In the new situation, we’ve had a conversation focused on the problem and solution, not on the big card or Jira field. Better yet, we’ve come up with actual examples of what the thing must do, and probably even some examples of what it had better not do. And those examples can be run, and tell us right away whether they’re working or not. The developer would be a fool not to run them before calling “done”, and the team and Product Owner and stakeholders can see them run as well. This puts everyone on the same page as to what’s done or not.

As a convention, I always suggest the following. We know that once this story is done, there’s a good chance that someone will have a better idea, perhaps a refinement, perhaps even a replacement. That’s fine. But we agree that if the Confirmation Examples all run, this story is done as agreed, and whatever needs to be done next is a new story. This saves a lot of blame-passing. We don’t care who “should” have thought of a thing that none of us thought of. We thought what we thought, we figured out the examples, we made them all work. Good stuff, move on.

Summing Up

I’m always trying to move in this essential direction, of making what we’re doing more concrete, improving understanding by having everyone involved from the beginning of a story, and adjusting the feedback loop so that bad news (bug reports) are made more rare, because we essentially wrote them before we started.

In the real situation, we’d have to start with the people, their needs and concerns. We’d want to understand why long stories seem important to them. We’d want to look at whether they feel safe, and so on.

I’d be confident that as they move toward the Confirmation Example style, they’ll find it more comfortable both for developers and business-side people, because communication becomes both more clear and easier, and because the effort’s status becomes far more transparent, with greater confidence in what’s working.

Pattern?

Is there an overall pattern, of which this idea is an example? Sure, there must be. It’s essentially the same pattern as Test-Driven Development, to the point where we can call it Acceptance Test Driven Development or Behavior Driven Development or, thanks Dan, Example-Guided Design.

The name’s not important – or maybe it is, I don’t know. The idea is definitely important. And the pattern? Maybe it’s called Move Blockers to the Front, or Get Bad News Early. I’m not at all sure, the question just came to me, but I’d bet that I use this thinking a lot, and perhaps you do as well.

TL;DR

Here, the idea is quite simple: we have Confirmation Examples that really define our story, backed by as much Conversation as we needed, driven by a small card that is, as Alistair Cockburn once put it, “A ticket to a conversation”.