Get More Out Of Your Sprint Demos Through Storytelling

We all love a good story. A story that takes us through the journey of the teller, clinging us to his every word. A story like that is easy to understand and can be retold to others without losing too much of its original context.

We tell stories all the time, we tell them about our holiday, weekends, a nice restaurant we went to. Yet, stories are not as often used in a business context as they could. In IT we’re mostly using stories to deliver or get requirements across, but even though they are called stories, they are nothing like a real story you would tell your kids. Instead it follows a strict format and has all creativity stripped from it. These stories are not only missing creativity, but often they lack the bigger picture and setting to be compelling.

Because why would you make a requirements story compelling? They’re only looked at once by the team before they get archived, right? In this article, I want to highlight the power of actual storytelling in an IT setting, more precise during a sprint demo in front of stakeholders.

Get People To Care

If people can’t follow a story due to reasons it not being well structured, too complex or brought with zero passion they will lose interest instantaneously. This happens during almost all sprint demo’s I’ve attended and it’s all due to the way it’s presented.

How do you expect to cling a stakeholder to your story when all that is being told is:

We upload a file here, then we initiate the processing by clicking the “process” button. This will unzip the file and data is extracted. You can see the extracted data here. We then proceed by…

At this point you’ve lost all stakeholders who don’t know the context, requirements and process. The only people that know what’s going on is the team and hopefully the product owner.

What is actually going on in this process? What is the goal and why does the system do what it does? Bringing this in a story will give more context and takes your stakeholders on a journey through the requirements and bigger picture.

A story could look something like this:

Our suppliers provide us with their invoices every last billing day of the month. They will need to use this upload function to get it in our system. They always send the files zipped due to the large number of invoices. Eventually the zip gets unzipped and all invoices will be processed to retrieve the billing codes. These billing codes are used by accounting to verify…

The latter is a story anyone can follow, it uses business context, human language and explains why these requirements are needed. Stakeholders are more interested in what’s going on in the application, now they can link the application to a process that’s familiar.

Which bring us to the next topic.

A Process Of Discovery

Software development is a process of discovery. Sprint demos are feedback moments where new requirements could arise and existing ones get fine-tuned. When you just walk through the functionality without a story to back it, the chances of discovering new requirement or fine-tune existing ones are slim.

A stakeholder who’s further away from the team could possess information that was not yet known, information that is potentially valuable. But maybe wasn’t deemed as crucial at the time of requirements gathering. A story paired with a demo could uncover an unknown requirement. The combination of “I know it when I see it” and a story are often powerful enablers for discovering new requirements and fine-tune existing ones.

An Overall Better Solution

The main goal of every software project should be to deliver a solution that holds value and is built correctly. The more we talk about the challenges we’re trying to solve, the better our understanding gets of what we actually need to develop or build to solve it. This understanding contributes directly to the overall quality of the solution.

Written by Sammy De Moor.