A story is a one-sentence statement that describes
Let’s say we’re tasked with creating software for online movie ticket sales. One story might read:
As a moviegoer, I’d like to purchase tickets online so that I don’t have to wait in line at the theater.
That one sentence tells me who it’s for (moviegoers/consumers), what they want (to buy movie tickets online), and why they want it (to avoid long lines at the box office). That’s a great start, but it’s just a start; there’s not enough information here to start coding. So stories alone don’t replace specifications, but they focus on the context: the what rather than the how.
There’s a lot more to writing a good story that’s beyond the scope of this book. A good book on story writing is Mike Cohn’s User Stories Applied: For Agile Software Development [Coh04].
Alistair Cockburn says that stories are “a promise for a conversation.”[27] We don’t have enough information to build the feature, but we do have enough information to start a conversation about that feature.
Requirements are replaced not by stories but by the interaction between the Product Owner and the developers, and the interaction between the Product Owner and the customer. Those interactions are where the rich understanding comes from to build the software.
And by the way, stories are typically written on 3x5 cards so there isn’t a lot of room. I usually give the team big markers, too, so they have to write in big block letters. We don’t want that much detail, and it’s okay to look for ways to try to make adding detail—adding “how”—as difficult as possible.
The long and complex process of writing everything down in English is inaccurate when it comes to code. Rather than just building a set of instructions the developers not only don’t need but will work better without, stories allow us to focus on the work, so developers are building in a way that’s rich with discovery, and that really is exciting.
Exciting and efficient.
In a traditional Waterfall process the plan itself often takes on a life of its own, so there’s a palpable sense of completion at the end of the planning session. The people involved in creating the requirements can feel that they’ve finished the project, but all they’ve done is get to where we think we’ve agreed on what this thing should look like once somebody actually does any work.
Then developers sit down to code it and realize that maybe 25% of the questions they needed answered actually have been answered: have we thought about this or that or this—and how do we handle that?
Stories are about making sure the focus remains on the development of the software itself rather than on the plan for the development of the software.
In Agile we say, “Barely sufficient documentation.”
Many teams spend so much time with specifications and design documents that they forget software development is all about coding. They end up with all these disjointed documents apart from the code. Instead, the code itself should embody all that knowledge. They’re so busy working on all those artifacts to document the system that they have no time to make the code itself expressive and easier to work with.
It’s the conversation that makes the development process work, and by far the most efficient way to build software is that collaboration between Product Owner and developers.
A story is finite and speaks of a single feature for a specific type of user and for a single reason, whereas requirements can be pretty open ended. When a story is finite it means it’s testable, and when a story is testable, you know when you’re done. This is absolutely critical for software developers because when we don’t know how a feature is going to be used, we overbuild it. This is why nearly half of all the features in software are never used.
Software developers overbuild because we’re scared that this feature is going to be used in a way we didn’t anticipate. If I know how it’s going to be used, I can build it right and build it for that need, and then I can move on.
A lot of “what-iffing” occurs in software development. That’s where the sorrow and unhappiness comes into our industry—that anticipation. Any time you have to anticipate is a recipe for misery, because you never know if you’ve done too much. You never know if you’re doing enough. You never get that feedback either.
No wonder developers age quickly.
So that whole idea of “let’s let development become a discovery process” is a very exciting thing, and a powerful way to build software. And then, of course, developers start doing things like prototyping and showing their work in progress that inspires, from the customer, all sorts of new ideas for features and functionality.
Software developers do still like to be definitive, and I don’t mean to imply that this sense of discovery is a slow, meandering journey. We can and should build acceptance tests—and there are automated tools to do this for us—and when that tool says “Yes, it passes,” okay, great! And we can move on.
We don’t have to stay up at night wondering, “Did I cover that case or this case?”