Story Writing
Once upon a time there was a team who worked at a big company… and they all lived happily ever after.
But what happens in between the introduction and the happy ending, what did the team do? Well to find out, we have to read the story. Just like in fairy tales, all the good stuff in an agile team happens with stories.
In Agile (just like fairy tales) all the work to be done (or should we say requirements) are captured as Stories. Even when the requirement seems obvious, writing it down as a story is a great way to ensure that everyone is truly aligned and prevents the tire swing type of problem:
The customer wanted a TIRE swing but wrote a TIER swing. Stories bring a shared understanding of the problem that the user wants solved, sometimes we even call them “User Stories”.
As with fairy tales, stories can vary in length from around half a day’s work to several week’s work, but the best stories in Agile are around 2-5 day’s work. This is small enough to understand and show progress, but big enough to represent some business value and deliver in it’s own right. Just like fairy tales, sometimes not everything fits in a story and most teams call this an Epic which is larger than 2 weeks work. Epics are usually broken down into multiple Stories and Stories themselves can be broken down into multiple Subtasks.
User Stories describe the problem that our customer has and why they want that problem solved – Who, What and Why of the problem. A useful template to start writing user stories in is the Connextra template:
As a <role> I want to <capability>, So that <receive benefit>
Quite often the Role is a custom Persona that your team has researched/created for one of your customer segments (don’t use someone in your team as the role).
For example:
As a child I want to swing from the tree, so that I can have fun in the playground.
As you get better at writing stories you don’t need to follow the template but always capture the Who, What and Why of the problem.
Even when the user story is written, it’s still important to have a conversation with the team. Think about the phrase:
I like pizza when its hot
The fastest way to clarify which of the 3 possible meanings of this phrase is to have a conversation about it. Before we start work on any user story we should have this type of conversation about whether to buy chilis, turn up the oven temperature or the weather.
If our story doesn’t end with “they all lived happily ever after”, then we also need a way to decide when our story is finished. We can do that by including the “Acceptance Criteria” (or AC) in the story. The ACs can be simply a list of a few bullet points and they answer the question:
What will we see when the story is finished?
There are other formats for ACs too such as Behavior Driven Development (BDD) for more advanced teams but here’s a simple example:
- Can swing from the tree without hitting anything
- Won’t easily fall off
- Cost less than $100
So now we know that the team who worked at a big company (and smaller ones too) are going to start off writing Stories before they start doing their thing so that they are all on the same page about what they will be doing. Then they all lived happily ever after.
Book Reference: User Stories Applied, Mike Cohn