Welcome back to On The Inside! This is part 9 of my agile adventure at Allthings, a technology startup in sunny Dundee building a group project collaboration tool. If you’re new to this series and I’d suggest reading part 1 which is all about diving into the deep-end! If you’ve stumbled upon this post but have missed last week’s edition of On The Inside then you can find the last episode here. I’m trying to give an honest, personal, warts-and-all account of our journey…
There are many times during the agile sprint cycle that you might find yourself facing a story that just won’t fit. It might be an epic that you need to break down to find and explore the problem. It could be a whole topic that has too many points for the intended date of release. It might be the last story at the sprint planning that just won’t fit into the sprint. Or it could be a new unknown feature that you want some quick feedback on. Whatever it is, it needs to be broken down so you can move on.
Image: Agile Ramblings
Breaking a story down is the process of looking at and exploring a story with the goal of making one or more smaller stories from it. The art is in making sure that each new story is still a complete story in its own right – it’s one of the skills needed to make a great agile team. It relies on good communication skills and cooperation. It forces the Product Owner and team to use listening skills and really understand the goal of the story that’s in front of them.
Here is a simple example story to help explain:
• As a user I want to be able to see a list of my available templates, create new ones, edit and delete existing ones and then use them to create multiple Lists.
This isn’t a very good story but hopefully you can see how stories like this could come about. I think of this as an epic. It’s a story too big for the team to start work on.
We could split this story into two parts. One with the operations of template management and the other the use of a template:
• As a user I want to be able to see a list of my available templates, create new ones, edit and delete existing ones.
• As a user I want to use a template to create multiple Lists.
When breaking stories up we need to make sure that the slices of the story we produce are stories in their own right. We can tell if they are by making sure they’re still “INVEST-able” using Mike Cohen’s INVEST test:
Independent – It doesn’t rely on any other stories to be completed.
Negotiable – It’s not atomic. It can be broken down.
Valuable – Completing this story is valuable to the user or business.
Estimable – It’s possible for the team to give the story a points value.
Small – It’s smaller than a sprint and usually in the order of 1-3 actual days worth of work
Testable – There is a clear plan for how we would verify that it works once it’s complete.
One way to help retain the value in our split stories is to try to split them into end-to-end. For example, if you imagine the layers of a system stacked on top of each other like the layers in a cake: UI, Business Logic, Data Access. Traditionally IEEE 830 Requirements would specify the features in layers concentrating on one layer at a time, horizontally. This leads systems to be developed layer-by-layer with the value of a the system or cake only being delivered once the last layer is finished.
Splitting the story vertically is like building one slice at a time. A little bit of each layer is involved in completing a story and the end result is a valuable, testable and vertical slice of the original problem.
So how do we take a vertical slice of our story?
As a user I want to be able to see a list of my available templates, create new ones, edit and delete existing ones.
The obvious way is to take a Create, Read, Update, Delete (CRUD) story like this and split it vertically by operation like this:
• As a user I want to be able to see a list of my available templates.
• As a user I want to be able to create new templates from scratch.
• As a user I want to be able to edit existing templates.
• As a user I want to be able to delete existing templates.
Are these really independent? In a typical project, it won’t be the customer who experiences the template UI first it will be whoever is testing the system. They will have the same problem in that they can’t use the template system before all the stories are developed, so they can’t start testing until at least the create and the view templates stories are complete, creating a dependency between them.
This can result in an accidental glut of work delivered to testers late in the development cycle as only when the last story is complete can they start verifying any of the stories. This can make it harder to avoid carrying stories over to the next sprint.
We could try to provide temporary screens to get the templates into and out of the screen. You could also try to get testing started earlier in the process, but that’s extra work and feels like fixing the symptom and not the problem. It all begins to feel like a big waterfall approach of ‘deliver everything all at once’.
An alternative way to split this story is to split by data rather than by operation. Take a template, which is presumably a collection of metadata about the template and instructions for how to create a list and do all the operations to part of it:
• As a user I want to create, list, edit and delete a template containing a Name.
• As a user I want to create, list, edit and delete a template containing the template Creator details.
• As a user I want to create, list, edit and delete a template containing instructions for creating Folders.
• As a user I want to create, list, edit and delete a template containing instructions for creating Lists.
• As a user I want to create, list, edit and delete a template containing instructions for creating Things.
• As a user I want to create, list, edit and delete a template sharing permissions.
Now we’re doing all the operations to a subset of the data of a template rather than all of one operation to all of the template and we’re doing everything end to end with only part of the template each time. Now we can start developing, testing, learning and releasing parts of the final template feature as more end to end features appear.
Having someone in the room or someone playing the role of the customer while you’re breaking down stories can help a lot to make sure that you’re stories really are INVEST-able. They will keep the group focused on the testability of stories and their value to the customer.
Practice breaking down stories with your team. It can be fun and can help get you communicating in different ways. One way I’ve done this is to choose stories that have nothing to do with work like “Go Glamping”, “Get a rocket into space” or “Make a boat to sail to America” and have some fun with the team breaking them down.
A good technique I’ve used is to consider each layer individually and brainstorm a cost spread of solution at each layer e.g. Build the database to Provide test data in a text file. Then after this, walk through the layers top to bottom picking one solution from each layer. Gojko Adzic calls this the Hamburger method in his great post on the subject.
Operations and data are only two ways to break stories. There are many approaches to splitting stories and you should try to learn as many as possible to expand your toolbox. Try a few of them out on the same story and then simulate the sprint by drawing whiteboard pictures of what each story delivers and testing the result to make sure it is still INVEST-able. Experiment and see what works for your team.
Splitting spikes is an area that needs a little more thought. You’re in Cynefin Complex domain so you have changed your approach to a probe-sense-respond mode. Try to define the question that, if you had answers to, would let you continue. For example “If I knew how to read from USB device X and the data format returned I could continue”. Then build the minimum code to answer those questions.
Richard Lawrence has a fantastic flow chart summarizing some of the approaches to story breakdown here. He suggests that you start by looking at splitting by Workflow steps perhaps identifying some that don’t have to be done on the first iteration, move through trying to split by Operations, Business Rule variations, variations in Data, Major Effort and Simple/Complex ending with spikes as a last resort.
Marketing teams could learn a lot by practicing how to break their type of work into “INVESTable” stories, but more about that in another post…
As always, if you have any questions about how I break down stories or would like further advice, please leave your questions in the comments below or you can contact me either on twitter at @allthings_io or via email at firstname.lastname@example.org Thanks for reading!
Image: Gojko Adzic