Like so many artefacts produced and consumed during a software project keeping them up to data and simple is vitally important.
For an agile project where the aim is to keep the number of such artefacts as low as possible this should be straightforward but it is easy to let this sort of project hygiene slip. After all if everything is working well the cards only live for a short time, they collect data during the iteration and perhaps into testing but after that they are of little value. If they live for such a short time why is it important that the cards be written clearly, identify where they came from for traceability etc.
Keeping the story cards clean helps the team by reducing the number of times related information is sought. For each discrepancy between the card and its context someone needs to work out what the differences are, if they are important and what should happen. By not reflecting this on the card as a simple note edit it is likely that someone else will need to go through the same process.
It is arguable that if this situation arises that the stories are too big and the cards are spending too long in development. I like to make sure that each story is a coherent vertical slice of functionality with a starting point and user visible result. Sometimes it is not practical with this constraint to slice the work into a story that is both quick to implement and satisfy the requirement to deliver a useful and visible result.
It does and should not take much to keep the wall clean. If it does then story wall hygiene is probably not your biggest problem.
The Existential Terror of Battle Royale
2 weeks ago