The London Agile Discussion Group were talking about How to Split User stories which is a topic of great interest as it is hard to do this quickly but well and it is always great to hear how other people deal with similar experiences.
You start a project and depending what side of the fence you sit on depends which issues/experiences you may have. For me in the Business Analyst role on a new project you need to ensure that there is a clear vision for the team to work towards. Then you start working on the requirements with your Product Owner/Customer. This is where it can get interesting as even what seems like the most basic requirement actually probably isn’t. A request for a login page seems quite innocent but if that if the only acceptance criteria is that Job Blogs can login and that is what is delivered I’m pretty sure most customers will say that is not what I wanted. There are different levels of requirements, bronze, silver and gold. What is needed now and how much time do they want spent on this requirement. Do they need registration as well, do details have to be collected, does it need to link to LDAP? Even a story that seems basic need to be split a little more.
Why do you split stories? We came up with a few reasons but there are a lot more:
- Promote discussion and understanding
- Several people can work on it
- Reduce time to deliver and get feedback
- Fail fast
- Fit into an iteration
- Improve acceptance criteria
- Get better requirements
There are different ways to slice up a story, vertical or horizontal. Most developers trying to break down a backlog into smaller chunks will automatically head down the path of using a “horizontal slice.”
A horizontal slice is basically a slice through the feature or backlog that horizontally divides up the architecture and this isn’t the wrong way of thinking about its as most things are built this way. If you were to build a house, you would slice up the project horizontally. First you would pour the foundation, then put up the walls. Finally the roof goes on and many more steps, leaving the finishing work for last. This same thinking usually gets applied to breaking up backlogs in Agile development. It would seem silly to build a house where you finished one room completely at a time.
There is a distinct difference though, between developing software in an Agile way and building a house. In Agile software development you don’t know exactly what you are going to build until you are done building it. With a house I hope this isn’t the case! You start with some blueprints that you have drawn up ahead of time. You know exactly where each wall will be and where each outlet will be. You may have even built houses before that are very similar. When building software, unless you are taking a waterfall approach and planning everything upfront, you don’t know what you are really building until you are done.
To be Agile means responding to change. Building a house, you do not expect the customer to say “hmm, yeah, I don’t really like that wall there” or “actually, I am thinking we are going to need 5 bedrooms now.” In developing software when the customer can see how it is turning out, requirements may start to change and new ideas appear.
Vertical slicing is basically building one room at a time. It is not functional as a house straight away, but we can pour more foundation, change how we are going to do the rest of the rooms and even knock down the walls and start over without incurring a huge cost. The point in building our software “one room at a time,” is to give the customer a chance to see the product as it is being built and this enables them to test it out. They can’t live there until it is all done. But, they will have the ability to step into a room and envision it with all their furniture in there.
Customers don’t care about foundations and framed in walls. As a developer, you may be able to look at some foundation and framed in walls and envision what the house will look like, but the customer can’t and worse how can they test it? Vertical slicing in software development is taking a backlog that might have some database component, some business logic and a user interface and breaking it down into small stepwise progressions where each step cuts through every slice.
The idea is that instead of breaking a backlog up into the following:
- Implement database layer for A, B and C
- Implement business logic layer for A, B and C
- Implement user interface for A, B and C
The backlog is broken up into something like:
- Implement A from end to end
- Implement B from end to end
- Implement C from end to end
Developers think about the horizontal slicing when planning out the implementation of a backlog, wanting to implement things by building one layer at a time. Thinking about how to break apart a backlog into vertical slices requires a step outside the understanding of the code and implementation, instead thinking about the backlog in small pieces of working functionality. There is always some progression of functionality that can be found in a large backlog. Meaning there are always smaller steps or evolutions in functionality that can be created in order to produce and end result in software development. Sometimes the steps that are required to break up a backlog vertically are going to result in a bit of waste. Sometimes you are going to purposely create a basic user interface that you know you are going to redo parts of as you implement more vertical slices. It is better to plan small amounts of rework than to build up an entire feature one horizontal slice at a time and have to rework huge parts of the feature that were not planned for.
Vertical slicing is about delivering working functionality as soon as possible, delivering working functionality as soon as possible is important and valuable.
There is a good flow chart on how to spilt stories how to Split a User Story that helps you break it into smaller sections and obviously mentioning INVEST that we reviewed in the meeting. Stories should be:
We then split into small groups to run through an exercise on Elephant Carpaccio. You ideally need 2 hours to run this and you need developers for this. We decided to do it without the coding and show and tell. You need to make a calculator, what are your stories for this, how do you split up the project and how do you ensure you get value sooner. I think this exercise was an eye opener and I’d like to run it again as it makes you think, trying to work out the priorities and what would be most useful. I also think it was good as it tried to make you split up the stories as small as possible but each story had to add extra value and could be demoed. I’d recommend this to teams to help developers see the different on how you could split stories. It was a very interesting session.