Tell a story with your project plan

May 25, 2011

This blog post is a summary of my lightning talk at XP2011

I needed to fail with modern methods for requirement gathering in order to understand old methods for requirements gathering. Many software projects write requirements in what is refered to as “user stories”. But a use story is not a story at all. There’s no drama, no action and no resolution. Instead, user stories are often just a bunch of interactions between the user and the system laying in a big heap in a shoe box. Or even worse: In an issue tracking system. Using the form of use cases, a requirement form that had failed me in the past, I have reinserted the drama into my projects.

Humans have used stories to communicate and to think about the world for as long as we’ve had language. Some elements are common to all stories: A conflict upsets the order of the world. A hero enters the scene. Through the actions of the hero, the world is set back into order and the all is well in the world.

Here is a for a project that makes a webshop, the story of desire:

Some person craves stuff (the conflict)
The webshop(the hero) welcomes the craving user to its front page
The webshop lets the user picks stuff
The webshop lets the user pay
Some more stuff happens through the webshop so that the stuff is delivered
Even more stuff happens
The craving person gets his desire fullfilled and the world is set back to the way it was supposed to be

Not the most exciting story, you say? Well, you asked for software system requirements, not for literary masterpieces! The use case illustrates my point: A narrative lets us understand the purpose of the system (the hero) in the world and the operations the system needs to perform in order to fulfill its purpose. The first and the last step of this narrative happen without reference to the hero, setting the stage and providing the coda (look it up!), respectively. Each of the action steps between clearly states what sort of capability needs to be built for the system.

The story of desire is a made-up story to illustrate the point. Here is a simplified version of a real story in my current project - the story of disturbance:

There is a disturbance in the balance of production and consumption of electricity (the conflict)
Already, the system (the hero) has received from power plants information about their reserve capacity (this is a story of its own, but for another day)
The system shows the Operator (the real hero!) power plants with reserve capacity
- Variation: The operator filters the list of power plants using some criteria
The system lets the Operator activate the reserve capacity at a power plant
The system sends an activation request to the power plant in question so they can be activated
The system shows the operator what reserves are currently activated
The system lets the user deactivate reserves
The system sends all activation requests to the accounting system, so the power plant can get paid
The balance is restored

If you wonder why this disturbance in the force is a bad thing, take a look at my blog post about xxx. You’ll quickly see that the balance of electricity may impact whether or not my beer stays cool. Clearly an important concern.

This story is a bit messier, since it deals with more real-world problems. Together with all the details I let out, it also has the disadvantage that it will take one team about a year to develop. Our customer is a bit too eager to get some software out the door to wait for all that.

So, we present: The impatient story of disturbance

There is a disturbance in the balance of production and consumption of electricity
Already, the system has received from the old system we’re replacing information about power plant reserve capacities
The system shows the operator power plants with reserve capacity
- Variation: The operator filters the list of power plants using some criteria
- Variation: The system updates the view it receives new reserves
The system lets the operator activate the reserve capacity at a power plant
The system sends the information about the activation to the old system we’re replacing for further distribution
The system shows the operator what reserves are currently activated

Variation: The system shows the operator what reserves have been activated at a given power plant
Variation: The system displays a chart of what reserves have been activated at a given power plant

The balance is restored

During the start of our project we wrote about 10 stories like the original story of disturbance. The stories were written by small gangs each consisting of developers and users or other domain experts. The gangs would swap stories and improve each others work. Meanwhile, the product owner and the project architect would try and pry apart a story so it could be delivered by a single programming team in the order of about 4 months.

For a single delivery, we would write an impatient story. Each action step or variation of the “impatient story of disturbance” became an item on the backlog of the programming team. I’ve left out about a thirds of the stories to keep the text of the blog post down. In addition, the team had about 5 technical tasks, such as performance testing. Each week, the team would deliver on average two such items.

After a few months, we have delivered the first increment in a system that tells a new story to the users, but a story they recognize. We have taken the task that they use their existing system for the most and made it easier and faster to use. The result: Happy users. And cold beer. We hope.

Notes

This approach has very much the same vision as Jeff Patton’s user story mapping and Effect maps. The approach of linear textual stories is one that works well for me. I urge you to find an approach that works even better for you. My stories use Alistair Cockburn’s style of use cases from “Writing effective use cases”, but with one changes: I simplify the writing of variations to better support the linear flow and avoid detail. They are roughly at what Cockburn describes as “kite level”.