The Story Card Is Not The Story

At Eden we’ve used a number of different options for tracking work to be done on projects. In the early days we used Basecamp tasks. We then rolled our own system, which we’ve since abandoned due to a gradual shift in our business practices. We’ve used Pivotal Tracker extensively. Whilst we still use Tracker a fair amount, on one of our new projects we’re currently using index cards stuck to a kanban board, with Google Wave for extended documentation and discussion.

In the past, we’ve spent a bunch of time arguing about which of these devices better and which is worse, with a view to settling on the “best” system. The merits of simple systems over complex ones, and digital over analogue, have been endlessly debated. I now think that all of these arguments miss the point.

A couple of weeks ago, Enrique spent some time teaching us an early version of our one-day agile workshop. Through the ensuing discussion, I finally got to an important insight about what a story actually is, or rather what it isn’t.

The story is not the terminology, or which precise language you use to describe it. It’s not the text on the card at all in the fact, or even the card itself. It’s not the line in Pivotal Tracker and it’s not the task in Basecamp.

All of the tools we use represent some facet of the story, and help kick-start discussion. They remind us of the story, but they are not the story itself.

The story is simply the team’s understanding of the work to be done: nothing more.

This understanding reframed my view of the endless cards vs online vs Tracker vs everything else debate. These are merely useful props: methods of communicating within the team in order to achieving shared understanding. Granted, some tools are better than others. But they are just that: tools. Nothing should be sacrosanct: we should feel free to replace tools and methods that are failing for a particular client, even if they’ve succeeded on other projects. I now think settling on the “best” system is a vain exercise: we’d spend our time much better simply by properly listening to the customer and doing what they say.

The same principle applies to the almost-as-endless UX/Design communication methods fight. Should we use Balsamiq mockups, or HTML wireframes, or Photoshop mockups, or Sharpies and paper? Answer: use what works. Use whatever tools you need to get your message out into the collective consciousness of the team (that includes developers, designers, testers and customers), so that the work can get done to the customer’s satisfaction. These methods are simply ways of getting messages across: they have differing emphases, and carry different risks.

Often I think the whole way we approach the tools debate is wrong. We ask: “how can we use our favourite tool/method to track the metrics for this project?” Shouldn’t our question instead be: “How can we ensure we are communicating properly with the customer so we can deliver what they really want?” The tool question then becomes secondary and the critical issue of good communication becomes paramount.

The story card is not the story. Let’s ensure our projects serve the customer rather than our favourite tool.