Writing software with the grain

Exploring the humanity of Agile methods

1 2 3 4 Page 2
Page 2 of 4

User stories

Human beings have told stories for all of recorded history. We tell religious stories, political stories, family stories, epic stories, stories just for fun, stories of bravery, stories of cowardice, stories of love, stories of loss, stories of war, true stories, and false stories. The way in which we narrate the events of our day even mimics the pattern of a story. Stories serve to explain our origins, reinforce our identity, teach ethics, inspire us, and entertain us.

If you wanted to define the metadata of story, you'd have three basic entities:

  • Plot: The sequence of events narrated by the story. The plot reflects changes in the setting and the state of the characters in some meaningful sequence over time.
  • Setting: The context in which the characters are placed in time, location, and circumstance.
  • Characters: The personal agents about whom the story is told. They interact with one another through the events of the plot in the particular settings in which they are placed.

Stories are human and are told by humans everywhere all the time, because they mimic the form of our lives. Your day at work yesterday might not seem particularly worthy of song, but it meets all the requirements of a story: it is a story.

Now think back to that spec document again. When you read -- or are guilty of having written -- text like this:

2.7.1.8.2. Upon receiving the customer purchase order line item change order non-repudiation request document, the system shall produce a customer purchase order line item change order non-repudiation response document, mapping the customer purchase order line item change order non-repudiation ID to the...

You are left to wonder, to the what? To the ... time to go see what's new on the front page of Digg or in my RSS reader? Text like this creates minds ready to be plundered by Twitter, IM, email, and the ready satisfaction of a new browser tab and our favorite bookmarks. In a wired world in which we're already having trouble establishing deep focus and sustained concentration, we can ill afford documents like this. They do not engage and do not satisfy. But why?

Specifications don't narrate the events happening to a person in a particular place and time. They talk about the features of an abstract thing called a program, and nobody ever made friends with a program. There's nothing especially life-like about specs; that is, there is nothing in them that is like life. Rather, they try to reduce a piece of software to a collection of law-like statements about the software in its essence. Instead of describing what happens in the life of a program and the people who use it, they rush straight for abstraction, trying to describe what the program is one subparagraph at a time, repeated dozens or hundreds or thousands of mind-numbing times.

Sometimes this is the right thing to do. In the Western legal tradition, we don't rely on sayings or parables to define the law; instead, we use spec-like writings that describe in exacting detail what is lawful (or unlawful) in specific circumstances. Likewise, when we describe a file format or a communications protocol, we want to state in exacting detail what shall or must or may or must not happen when such-and-such a state obtains or such-and-such input is processed.

Writing laws doesn't feel natural to most people, although it does to many developers. The act of programming converts the imprecise and untidy world of human activity into law-like machine instructions. Even though the languages and tools application programmers use today operate well above the level of individual op codes, we are still writing programs for what amount to entirely mechanistic Turing machines. Making the translation from mental process to algorithm -- when it is even possible -- is a specialized skill that developers can enjoy and do well, but it is not typically a skill shared by the other members of an Agile team. Customers and product owners define the products we build, but they are usually not good at converting their ideas into laws. We shouldn't ask them to do so.

Enter Agile's insight that requirements should be captured in story form. The Agile community has debated the precise definition and format of user stories, but consensus is universal that story backlogs are not the same thing as spec documents. Rather than describe the essence of a program with law-like statements, stories narrate the interaction of a program with its users. They have:

  • Characters ("As an administrator," "As a truant officer," "As a Wayne Newton fan")
  • Plot ("I want to disable a user account," "I want to update a student's attendance record," "I want to find all covers of the song Danke Schoen produced during the selected date range")
  • Setting (which is implicit in the area of functionality being narrated)

User stories have many advantages, but fundamentally they capitalize on the normal human tendency to retell our lives using story. Unlike specs, stories require us to do little abstraction -- to keep a relatively simple mental concept of the program we are describing in our minds at any given time. We simply follow the characters and their actions, just as we've been doing with all kinds of stories since we learned language. It's the human way to describe software.

1 2 3 4 Page 2
Page 2 of 4