There’s a lot of excitement about getting to shorter iterations. But with a shorter iteration comes a higher degree of difficulty. One of the problems with shorter iterations is getting all of your user stories to fit into them. For many stories it is no problem, but then there are the stories that seem to only be doable in the time it would take to do two or three iterations. What can be done? Is it even possible to fit all stories into a short iteration?
Before we get too far, consider this. Prior to Agile, what was the incentive to break a large task down into smaller chunks? If you thought it might take 2 months, why not take two months? After all, the release isn’t for 6 months. So, prior to Agile, even if something could be broken down, there wasn’t really any reason to do so. As a result, we’ve had few reasons to build up our bag of tricks for breaking tasks down. Rest assured, there are many techniques for breaking big user stories down into smaller user stories and in this post I’ll show you one of those techniques.
Fitting User Stories into a Short Iteration
The diagram above represents a story that has a certain amount of value. In order to get that value, we have a bunch of work to do. That work cuts across the front end, the middle layer and the back end. An obvious way to split up the work is to do it a layer at a time.
But a user story is only a user story if it provides value to the user. Splitting a story up into “As a user I want the backend for X,” “as a user I want the middle layer for X,” and “As a user I want all of the UI for X” does not provide value until all three stories are complete. Stories need to provide value on their own.
Instead of breaking a story up into layers, try splitting it up by value. In this diagram, the original story has been broken up into three separate stories, each of which holds value in and of themselves. As a result, each story requires less work to implement. This process can be repeated (if desired) until you can no longer derive stories that still provide user value. At that point, each story is already as small as you currently know how to make it.
A typical example of breaking down a user story is “As a user, I want a calculator function.” This might be for a mortgage application, where the user wants a handy calculator that they can use as part of the application process. One might be inclined to provide a full-function calculator right out of the box. But it may turn out that all the user really needs is to be able to cut and paste numbers out of mortgage forms, into the calculator, add them together or subtract them, and then paste them back into the form.
If you are concerned that the calculator won’t have enough functionality at release, consider that (at least in this contrived example) they can always do what they want another way. But for some subset of users, you will have provided just what they needed. Based on user feedback you can then provide the next level of functionality. In just two short releases you will have provided more of what the end users really need than if you had predicted usage and done just one larger release.
You don’t need to split stories indefinitely, you only need to split them until they fit into your desired iteration length. As you split more and more stories, you will find that it gets easier and easier, and you will start to think in terms of smaller units of deliverable user value.
