This post is based on an experience I had a few years ago.
It gives you a clear idea of how to break down user stories.
I also give you an example of a complex scenario where I broke downa user story into 7 small stories
My experience of NOT Breaking Down User Stories
I worked on a team that was new to Agile.
They had never broken down stories vertically before.
And the Business were fairly new to the vertical slicing.
So when we went into Sprint Planning
The developers would say
“Those stories are too big to go into a sprint”
Then they would say
“We need some technical tasks to break it down”
BUT
This NEVER resolved the problem
Why?
Because we still would get to the end of the sprint with only half the development complete.
And the sprint review would end up a demonstration of code INSTEAD of valuable features.
Boring for all stakeholders whom the sprint review is designed to please.
So as the Business Analyst / Product Owner I took it upon myself to attempt to find a resolution this problem.
Here’s how I did it…
Brainstorm Large User Story Breakdown
First, I picked a story that had been estimated at 20 points using the Fibonacci sequencing.
Then, I organised a 1 hour brainstorming session with the very people who had estimated it.
That was the developers & testers.
I took in some post-it notes and a few pens.
I asked them to write down in as much detail as possible every technical, testing and documentation task that they thought needed to be done for this story to be signed off as complete.
The result?
About 20-30 tasks from all the different views of each team member
It gave me exactly what was in their head about the story being too big and it was now on my post it notes.
A great situation to look for the vertical slice.
Some were duplicated but that doesn’t matter.
Duplicates are good. It means those tasks definitely need doing.
Looking for Vertical Slices for the User Story
Once you have the post it notes.
It’s time to get down to business
A little bit of Business Analysis
List all the tasks in Excel.
I used Excel because it’s easier to move them about.
But you could use Visio or Word.
Look for a value added task.
By that I mean one which talks about displaying something on the screen. Or moving from one part of the system to another.
Then I took each part of the non-value added tasks and split them right across the value added.
It’s much easier to explain with an example.
Example of Vertical Slicing the breakdown of my user story
The Story:
We needed to display 7 different fields from a customer record on the screen, which would be extracted from an xml file.
The developers thought this is how they would approach the delivery
Extract all fields -> Store all fields in the database -> Display all fields on the screen
But you can probably only do one part of that per sprint.
Which means?
NO VALUE
Here’s how I managed to break it down:
Extract field No.1 -> Store field No. 1 -> Display Field No.1
Extract field No.2 -> Store field No.2 -> Display filed No.2
And so on… Until a new story had been created for all 7 fields
This create 7 small user stories.
Within just a couple of hours , I had broken down a 20-point story into 7 x 3-point stories
But why is this better?
Benefits of vertical slicing User Stories
For a start, when we get to the end of a sprint, we will be able to see at least some of the fields rendered onto the screen.
This is great because it gives the user a fantastic opportunity to tell the team whether they are headed in the right direction.
And we can FAIL early – as a team – if we’re not.
It also creates a talking point about how the fields should be displayed BEFORE all fields have been displayed.
Another point…
If the development team got to the end of the sprint and had only extracted 7 fields but not displayed anything on the screen. There is no point in showing the user because they can’t give any feedback on the system.
This breaks one of Agile’s golden rules too.
Delivering value at the end of every iteration.
You might be thinking? Are these stories not TOO SMALL?
And yes, there may be an argument that they’re too small. But it’s much better to get to a sprint planning session and find that you need to amalgamate a couple of stories than it is to find you haven’t broken them down properly and the developers are complaining.
This is especially true for Business Analysts who are often responsible for bringing user stories from inception to through delivery in the sprint.
The morale?
Never stop looking for that vertical slice and always try to add value with EVERY user story.