The idea of stories originated with a very smart guy by the name of Kent Beck. Kent was working with other people on software development in the late ’90s, and he noticed that one of the biggest problems in software development sprang from the traditional process approach of using documents to describe precisely what we want—that is, the requirements. By now you know the problem with that. Different people can read the same document and imagine different things. They can even “sign off” on the document believing they’re in agreement.

It’s later, when we get into the thick of developing software—or even later than that, after it’s delivered—that we realize we weren’t thinking of the same things. Lots of people call this lack of shared understanding “bad requirements.”

Let me vent a minute here. I have the pleasure of working with lots of teams. And we often start work together by talking about their biggest challenges. And, hands down, the one I hear most is “bad requirements.” And then everyone points at that document. The document writer feels bad—as if he should have written more, or less, or used some cool requirements technique. Those who signed off feel bad at first, and then indignant. “Surely you didn’t expect I’d read every detail! After all, we talked about this for days. I just expected you’d understood what I said. I can’t understand your silly requirements document anyway.” And the people building the software feel blindsided. They muddled their way through those cryptic documents and what they built was still wrong. Everyone hates the document in the end. Yet we still keep trying to write a better one.

But misunderstanding the document is only half the problem. We waste lots of time and money building what the document describes, only to find out later that what actually solves the intended problem is something very different. You heard me right. Those documents often accurately describe the wrong thing. Documents usually describe what we need, but not why we need it. If the person building software could simply speak with someone who understood the users who will be using the software and why they’ll be using it, there’s often a more cost-effective way to delight those users. Without talking, we just never know about it.

Kent’s simple idea was to stop it—to stop working so hard on writing the perfect document, and to get together to tell stories. Stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used. Let me repeat that with more emotion. Right now you should stop whatever you’re doing and say this out loud:

Kent’s idea was simple. If we get together and talk about the problem we’re solving with software, who’ll use it, and why, then together we can arrive at a solution, and build shared understanding along the way.

A while back I began to notice that this entire story thing had gone a bit sideways; that is, lots of the people writing books, teaching, and using them focused on the activity of writing stories. If I had a dime for every time I’ve been asked how to write good stories, I’d have even more dimes than I collected a few chapters ago.

With all the focus on writing stories, I went back to Kent to make sure I wasn’t missing something here. Over the course of an email conversation, Kent explained where the idea came from:

So the idea is telling, and you know you’re doing it right if you’re generating energy, interest, and vision in the listener’s mind. That’s big. And it sounds a lot more fun than reading a typical requirements document.^[9]

But folks who start using stories for software development—and who still have a traditional process model in their heads—tend to focus on the writing part. I’ve seen teams replace their traditional requirements process with story writing, and then get frustrated trying to write stories to precisely communicate what should be built. If you’re doing that now, stop it.

In the book Extreme Programming Installed, Ron Jeffries et al. (Addison-Wesley Longman Publishing) describe the story process best:

If it sounds simple, it’s because it is. Just remember, simple isn’t easy.

The path to get to this agreement isn’t just a single card and lots of hand waving. The conversation goes best if it includes lots of things such as simple personas, workflow diagrams, UI sketches, and any other traditional software model that’ll help explain things. That way, you don’t have to just wave hands—you can point a lot, too. Whatever we bring into the conversation we’ll mark up, write on, correct, and change. We’ll even create a lot of things on the spot during that conversation. Use a whiteboard or flipchart paper. And don’t forget to take some “vacation photos” before you leave. Photos of what you’ve created will help you recall all the details of the conversation that would be difficult to write down.

Good story conversations have lots of words and pictures.

Keep the acceptance criteria you decide on big and visible during the conversation. This team uses flipchart paper to record as they go.

That’s all there is. That’s Kent’s disruptively simple idea. And, if you do it, I promise you it’ll change everything.

Unless it doesn’t.

For people used to working the old-fashioned way, this conversation can go really badly. They fall back into their old patterns of the person bringing in stuff, trying to work hard to communicate exactly what he wants to the other person, and the other person working hard to try to understand and then punch holes in what the other person is saying. If this goes on too long, they often feel like punching holes in each other, which is not conducive to getting things done.

There are some things to keep in mind to help these conversations go better. Happily, that’s what the next chapter is about.