Burn your story cards…Really!

In some organisations that I’ve worked in I have come across the practice of using story cards as hand over documentation for the support team. Now this goes against the grain of common Agile practice or recommendations that once a story has been delivered it’s basically worthless. You can essentially tear it up, burn it, step on it, do whatever you want; it can go into the bin as far as I’m concerned.

As part of your Sprint delivery, documentation update should be part of your practice process. To use story cards as hand over documentation is a very bad idea, and there are quite a large number of reasons why that is.

Firstly, a story card is meant to be a brief statement of what needs to be done. When I say brief it means brief, following the principles of Lean, or providing just enough requirement to enable delivery. What that means is that the story will have just enough information based on the experience and the capability of the delivery team. It’s not meant to document everything that people already know, or replicate existing documentation.

So it basically describes just enough information for the story to be delivered, and if you use that as documentation for the support team; the support team will have a completely different set of knowledge and capability. When they look at those stories they will most likely not be able to find enough for them to understand what was actually implemented.

Another reason is that stories should not be used as handover documentation is that they are often split based on the INVEST criteria. What that means is that is it very likely that you’re going to have a large number of stories that describe the evolution of a particular feature over the time of the project.

So early on in the iteration you might add a field with a simple text box and then later on towards the end of the project that text box becomes a super complicated input element that’s got tons of visual features to improve the usability.

When that’s the case you have so many stories to describe the evolution of the feature that the support team gets confused. They literally need to go through the entire history to find out which the latest is and which is the oldest. If they get confused then it will actually hinder their ability to support the system that they’re supposed to support.

So the history of the stories just complicates things, making the support team go through a large long story to make them understand what’s going on. Whereas, the most relevant information for them is what’s current; the features of the system that they’re currently supporting. The history of how that feature came about during the project is probably not as relevant.

Another challenge for the supporting team is when future project makes updates to those relevant fields and screens they will find that they need to update a large number of stories, and finding out which stories they need to update is going to be a complete nightmare.

Handover documentation should be concise, useful, and it should be lean. So this is what I recommend that all teams should do, make sure that you integrate documentation process into your Sprints as part of your practice to deliver documentation for the support team and for the document repository.

You can do that during the Sprint, or if you need to create a story to make it explicit, then that’s what you needed to do. Although I still feel that you should need a explicit documentation story, but that it should simply be part of every team’s development practice to provide documentation.

Doing this means far simpler handover process and improved ability for the support team to support the system that you’ve built. It would al mean it would be easier for future projects to be able to know what the current state of the technology system is.

Do this and you can go and destroy all the stories that you’ve written once the project is complete because the latest story of what’s being delivered has been documented and it has been documented well. Your stories will have served their purpose and they can disappear. That will also allow future projects to make changes to the system without having to refer to the large number of stories from the previous project. It makes it much simpler.

So I would encourage you to go and destroy your cards, burn your cards…Really!