When I train agile teams – especially Scrum teams – I always bring up my experience as a developer starting with eXtreme Programming (at least my company’s flavor of it – Kent Beck wouldn’t have approved). We wrote our own tracking tool for our product backlog (as none existed at the time) and taped our user stories (backlog) to a wall. We had a piece of yarn that denoted the release; everything above the line was in the release, everything below it was not. It was very old-school, but the benefits were that it was highly visible and it strongly emphasized the 3 C’s – card, conversation, and confirmation.

The Origin of User Stories

Turning the (with a hat-tip to Sherman and Mr. Peabody) to the late 1990s we learn about a little book called . In his book, Kent Beck laid out the set of engineering best practices and a framework for iterative development that he had been using. One truly innovative element was the concept of the user story. Different from a use case, the user story lays out a narrative of the work the user wants to perform. They’re in regular English – no technobabble – and are short – no longer than three sentences. The nice thing about stories is that they provided context from the user’s perspective: how is this functionality going to impact the user? How will they get their work done? What need are we fulfilling? As a developer, seeing a connection between the work we were going to do and the benefit it provided was critical – and gave us a sense of purpose for our efforts.

The 3 C’s of User Stories

In 2001, Ron Jeffries provided a scaffolding for good user story creation –  the 3 C’s. He defined them: card, conversation, and confirmation.

The Card

The first C stands for Card. Our stories were written on a 3″x5″ index card, so there wasn’t a lot of room to write a lengthy story. Index cards provide very little real estate, so you had to keep the story simple. And we’ve settled on the format for the stories as

As a <role>, I want <some functionality> so that <I get some benefit>.

The format is compact and gives us the necessary information. Not all user stories need to fit this model. I’ve seen good stories that do something totally different. If your Product Owner is new to the framework, though, it’s a great starting point.

The Conversation

For the second C – Conversation – we turn to when we begin work on the story. Developers pull a card off the wall, read the story, and then seek out the author (in many cases, the Product Owner) to have a conversation about it. Conversations are the backbone of agile (if you check the , you’ll see that three of the four values deal with communication).

We want to encourage teams to have conversations long before they start working on a story – during backlog refinement and sprint planning. They should be having conversations while they’re working on the story – here’s what I have so far; is this correct? Am I on the right path? And they should be having conversations when they’re done with the story – here’s what I completed; is this correct? Do you accept the work?

The Confirmation

The final C – Confirmation – dealt with the acceptance criteria; how did the team know they were done with the story? What should the software do when we were done? In some implementations, the confirmation – the acceptance criteria – were written on the back of the card. Again, there isn’t a lot of space, so just a few notes to remind the team what the system should do. Coupled with the continuing conversations with the author, these reminders are enough to guide development and testing. Today, some people use a tool like Cucumber to write their acceptance criteria and generate automated testing through the story. This is an interesting idea, but perhaps I’m a traditionalist. I prefer that the story stays in regular English as much as possible; leave the automation to the team.

Closing Thoughts

Everyone is at a different stage of their agile journey. Some can barely spell the word “agile” and others have been practicing a very long time. As a coach, I find it can be helpful to have a brief reminder of the origins of things. Why do we write user stories? What are the components of a good story?

Just because we’ve been doing it for years doesn’t mean that a refresher isn’t helpful. The 3 C’s are a core component of good agile implementations. And making sure that we focus on delivering all 3 – especially our conversations – can help an agile team reach even loftier heights.

Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)

Bill.