Breaking Down Customer Stories

Creating stories to work on is an integral task in agile software development. These stories are what the team of developers will be working on for the iteration. Where do the stories come from? Well, through discussion with the development team, the customer says what he wants. What types of stories does the customer ask for most of the time? The customer asks for epics. What makes them epics? They're just too large.

When writing software in an agile manner it is important to have very small pieces. You want something that can be completed quickly and delivered to the customer. Sure, it might be a small piece that isn't of much value yet, but that is good. The fact that it is small means that you can be constantly finishing pieces of the project. If your stories are too large you'll only be delivering at the end of the iteration. That's just not cool.

Steve Smith wrote a great blog post where he discusses very well how to break epics into vertically sliced stories. One major reason that doing this is of great advantage to you is that you will be able to get feedback from the customer. In Steve's example he talks about a registration page which is loaded with extra data including multiple addresses, contact info, and possibly other pieces. I can see a customer wanting to have something like this. So there are two ways we can approach splitting this up.

Splitting Horizontally

When you split horizontally, you will be delivering the entire solution at the end since each horizontal slice needs to be finished before anything is finished. So for the sake of argument why don't we say that the developer didn't create exactly what the customer wanted the first time. So now at the end of the iteration the developer finds out that the whole process should have been completely different. Now he goes and rebuilds everything in the next iteration because this one is out of time.

Splitting Vertically

Using this method we will quickly have the first small piece done. We can say that it is the ability just to create a user name and password at registration. Now when the customer sees this we get feedback. Maybe everything is fine for this part. We then go do the next part. Maybe we write the address section incorrectly. When the customer sees this he can let us know. Since we know early that there is a problem we can correct it. We may not have everything done at the end of the iteration, but at least we've got the most important parts done.

Since the customer can keep each of these vertical slices in ranking order at the end of the iteration he will have a bunch of working pieces. He will have stuff he cares about even if it isn't all there. If we had found out at the end of the iteration that we needed to make a change we wouldn't have anything done.

Conclusion

It is important to know how to split stories. Sometimes there are pieces of the story which can be vertical slices, but you should try not to have too many dependent tasks. It will make your software development work much faster and better.

Comments