Tuesday, 25 August 2015

Stories, short and sweet

Friends, Product Owners, Business Architects ... 

How many of you have written/read (user) stories in an Agile project? 

How many of you felt happy with the fate of those stories? 
Did your software development teams find them useful? 
Did your team attribute any defects to the details missing in these stories?
Do you find them adding value to the way you develop your product?

Let us forget about the stories that we have written or are writing for our project.
Let us pause for a moment and ask ourselves, "What are stories?"

A story, literally, has characters, settings and a plot. The following link gives a simple explanation followed by an interesting quiz to understand the three main parts of a story. Suggest you to go through it. (Parts of a story)

The ancient civilizations, especially in the east have effectively used stories and storytelling to pass on their knowledge across generations. These stories were easy to remember, some of them are retold even today and had some rather seminal insights.


Ancient Vedic School (India)

The stories that we use in our projects ought to be no different. Well crafted stories can help to effectively convey the knowledge about what needs to be built to the team that builds it.

Let us understand the parts of a story a little bit more so that we can craft our stories well.

1) The characters:

A story, usually, has two main characters - the hero and the villain. It may also have a supporting cast, which makes the story rich.

For our (user) story, the hero is the main user of our product. 

The villain need not necessarily be a person, it can even be a condition or hardship (phobia, lack of confidence etc.) from which the hero wants to get out of. 

In our software product, the villain is the pain point which we are attempting to solve.

A story with a hero and no villain is like a soda with no fizz. This is why the benefit/rationale of a (user) story is as important as the actor/hero and should not be trivialized.

The supporting cast for our story could be the other users who interact with our system, like administrators, technical support staff, guest users etc.

2) The setting:

The setting of a story refers to the time and place. Your story may be happening in the past, present or even the future. It may be happening in a bustling city or a haunted house. For our (user) story, the operating environment of the product, references to the prior art, application settings or a set of preconditions at which another story resumes can be considered as part of its setting.

3) The plot

This is the sequence of events and outcomes that moves the story on. A logical sequence is necessary to keep the audience engaged. This is why it is important for the multiple (user) stories in the backlog to be logically connected.

In agile projects, stories are prepared using a method known as progressive elaboration. Whether we are using the Epic->Story->Task (influenced by Mike Cohn) style or the User Activity->Task->Sub-task (as suggested by Jeff Patton) style, we may be wiser to use the three parts of the story suitably in each step of this elaboration.

Great stories are meant to be told rather than written. Some historians describe Homer, the author credited for the great epics of The Iliad and The Odyssey as a blind, wandering rhapsode. They suggest that the epics were written by some of his audience who listened to the stories he told.




History has also immortalized another great playwright as the "bard of Avon".

To make the best use of the our (user) stories, the story writers can tell them loud, with passion (like a bard!); in the requirement brainstorm, during the daily scrum, as a feedback in the demo or when raising an issue in the UAT.

The stage is set. The world is waiting. Go tell your tale ...