Agile Storytelling
In agile literature, stories are sometimes described as a “place holder for a conversation”. The thinking behind it is that the client and the development team (developer and QA when there is one) will sit together and flesh out the details when the story is ready to play. This turns out to not be the entire story. First the story has to go through the estimation process. In order to give an adequate estimate (not necessarily a precise one) some details need to be available already. The story is enriched by this first conversation. Second because during the development phase, the specifics of the story may change due to technical difficulties, new ideas or the discovery of new use cases. This simply means the story evolves and changes and gets more precise as it approaches completion.
Unfortunately, in the team I currently work on, this introduces friction. The big question is how detailed should the story be for QA ? And even if we agree on this, how are discussions and changes recorded in the story ? Even more importantly, who records those changes ?
Enters BDD story writing.
I recently shared with the team an article describing a recommended story format introduced by BDD. I hope this can be used to address the different changes in the story. From the short narrative and user scenarii written by the client to the use cases discovered during the development and QA phases, the BDD format enables to easily enrich the story “just in time”. It enables to keep track of the state of a changing specification. It leaves most of the non critical specifics out and it does not record the full discussion but simply its results. It is also a format that is easily accessible to technical and non technical people alike, both for reading and writing. I will be sure to report on our progress using this technique.
All this helped me realise a few things about Agile Storytelling. As the title implies it is akin to the communication technique called storytelling. The story facilitates the conversation between people with very different backgrounds. It sets the common vocabulary. It also builds a common vision of the story’s results and in the long term of the product. A key difference is that the story is not a one way message, it is written by multiple people putting their own point of view in a language that is understandable by all.
Did I mention that an agile project without well written stories and a clear definition of “done” is bound to fail ?
July 13th, 2008 at 11:01 pm
I am not sure what “well-written” actually means here. If it means it contains enough details and specificity for a developer to translate it into code and for QA to verify the resulting behavior in a program, then I am afraid it would remove much of the agility in Agile.
In my mind, being Agile should be like how the UNIX system was first developed by Ken Thompson and Dennis Ritchie. I wonder what UNIX would have become (or if it it would even be as popular) if they had needed to keep “well-written” stories as the code was written. If end-users and developers really share the trust and commitment that Agile requires, not having “well-written” stories should not be an issue.
This begs the question: Do users and developers ever can have that kind of trust and commitment?
July 14th, 2008 at 5:19 pm
The article attempts a description of how to build a good story and what are its characteristics. It is not about the amount of details but mostly about building a shared vision of what the result of the story should be. Also a story is changing until it is called finished by the user. At that point it can disappear into oblivion.
Second, I do not think it is only about trust. Trust is always a nice to have whatever the work and the process. It is certainly an important part of agile processes but it is not initially given. Collaborative story writing is an element to build trust but also goes beyond that. Everything that makes the process open and transparent helps building trust.