My classic article on Card, Conversation, Confirmation reflects the way we handled stories in Extreme Programming. We wrote a quick description of the feature on a card, talked it through with our Customer (think Scrum Product Owner), then created concrete testable examples to confirm that the feature did what we and the Customer wanted. For us, the Card came first.

Today, as the posting from the Organization That Should Know Better indicates, people fall more and more into writing requirements documents on the Card. The idea, whether expressed out loud or not, is that the story card should contain enough detail that it “makes sense” to use a standard format. C3 tried a standard format card in something like 1998 and realized it was a bad idea then, and we said so.

Chet and I were talking today about the Organization That Should Know Better’s tweet, and about how one might do stories today, especially in groups that, for one reason or another, cannot sit together. Might they not do better with a more elaborate story card? Well, let’s come back to that. Let’s start, though, with what we’d do today, if we were going to do what the Agile methods all talk about, namely a cross-functional team, including business-side and developer-side people, including all the people, and all the authority needed to get the product done. It might go like this:

We all get together with our Customer / Product Owner, and we talk about the product. What problems does it solve, how might it solve them. We’d tell each other stories about problems and solutions. We’d draw pictures of the product. We’d probably talk with real users or visit their sites and watch them work. We would conceptualize the product, trying to give the whole team a rather consistent view of what needed to be done. This would be a large-scale Conversation.

As time went on – more like days than weeks or months – we would begin to break out feature ideas, or specific capabilities, things that we could build. Because we’d be working with a one- or two-week cadence, or even a more continuous day or two per story, we’d quickly get very specific. This would be smaller-scale, more focused Conversation.

As we began to choose specific things to do next, we would of course need to Refine our understanding of those things. We would do so by becoming very specific about what a given feature, defined by a given story, needed to do. We would make that as concrete as possible, to be sure that we all, Customer and Developers, had a common understanding of what’s to be done.

Would we do that by writing a bunch of text on a card, or into a document, or into Jira? We would not. We would express the agreed capabilities as Examples of what the system should do. Where possible, those would be expressed as concrete executable Customer Tests. Sometimes, they might be expressed as drawings of the GUI or something less concrete, but where possible we would always be working toward a very concrete form of Confirmation that the product was now doing the new thing that we set out to do.

Then, we’d do the thing. When done, a day or two later, the concrete Confirmations would be working, and we’d move on to the next thing, repeating the process.

There might not even be a Card at all!

Back in 2001, we wrote a phrase on a Card, then focused on the Conversation, leading to the Confirmation. And we made it very very clear that if you didn’t have enough room on the Card for the story, you needed a smaller card. This was supposed to make people realize that stories needed to be small, and that the Card was not a requirements document.

Apparently, that rather simple information didn’t make it all the way to the Organization That Should Know Better. I’m not surprised, but I admit to being a bit disappointed.

So, today, I’m thinking, and I hope Chet agrees, because he’s sitting right across from me in the coffee shop, that we’d start with Conversation, move to Confirmation, then get the job done. We might draw pictures or take some notes, in some ad-hoc fashion that relates to the specific feature, but we’d shift as much of the concrete information into Confirmation, ideally executable Confirmation.

So what about the poor little Card? Would we even have them? I believe we would, in a few forms.

In The Nature of Software Development, I wrote about the “Five Card Method”, where we write “big ideas” on cards, then for those cards, write a few slightly more detailed cards. So there’s that.

And suppose we had a fairly large team, and we were working on a one- or two-week cadence, and suppose we worked on a few stories at a time, and suppose we wanted to display progress over the one or two week period. Then we might make a card or sticker for each story, and put them on some kind of wall display, showing the status of the cards as they moved through our process. Although, if our cards do go through some kind of staged process, we’d probably be wise to fix the process or do smaller stories. So the need for cards at this stage might be telling us we shouldn’t need cards.

We might not need cards at all, other than at the beginning. We would definitely not need cards with a consistent format.