Getting attached to stories
The physical manifestation of agile stories are a description of the requirement (in the form “as a [user], I want to [goal], so that [reason]”) written on an index cards with the acceptance critiera written on the reverse. The developer can pick up the card and work with it. Once the acceptance critiera are met it can be put in the pile of completed cards. If at any stage of the process we are not happy with the card, given that it is only a “promise for a conversation,” it can easily be torn up and rewritten. Tearing up cards is a powerful statement. We don’t like what we’ve written? That doesn’t matter, rip it up and start again. That works well in the opening stages of a project, but sooner or later the cards will be copied into a spreadsheet and this is where the problems start. We become attached to the story; good project management discipline demands we keep an audit trail of what we do. Suddenly it is not so easy to rip up the card. Maybe the initial story did not truly represent the requirement. More often than not the story title, and detail will remain the same, but a notes column will be spawned in the spreadsheet and the change to the story will be entered as narative in this column.
Clearly this is not a satisfactory way of doing things. Part of the agile coaching process has to be around the flexibility of requirements, and this includes refining, rewriting and splitting stories as the project progresses. The underlying scope of the project will remain the same, however inevitably the estimates will change. This is often difficult to accept if you are versed in traditional project methodology. At the beginning of waterfall projects you have certainty, clearly defined requirements and a plan to guide you by. It is towards the end of the project where deadlines slip, scope is managed by change requests and IT is cursed as being unreliable, untrustworthy and the breaker of promises. The reverse is true with agile. There can be a whif of unreliablity in the early stages of the project, particulalry if there is no clear plan. This is excerated with an excel storylist that changes by the day. The difference is that you are more likely to succeed in delivery when going with the agile approach.
The bottom line has to be an acknowledgement that there will be pain during the opening weeks of a project. Stories will be ripped up – delete them from the spreadsheet and don’t bother to keep an audit trail. Agree that the story list will be in a state of flux for the first few weeks. And once the project is settling down, once we have a better understanding of the project and are happy with stories, only then should we use formal PM tools with confidence.
One advantage of copying the cards to a wiki if you need to access them remotely, rather than using a spreadsheet is that you can delete and rewrite them to your heart’s content, and the page’s history is your audit trail. We all know that no-one will ever look, but at least you can reassure people that the history isn’t lost, and because it happens automatically there’s no overhead.
We tend to keep the bare minimum (title, estimate and a few notes) on the index cards, and put the expanded information, including acceptance criteria, on the release plan wiki page. Apart from anything else, the less you write on the cards, the less reluctant you are to tear them up if they need changing.
[…] Taken from Marc at http://www.dancingmango.com/blog/2006/10/16/getting-attached-to-stories/ […]