Stories often start out too big. Big stories are a challenge, and it is not always obvious how to deal with them. Its important that stories be small enough to estimate, to fit easily into an iteration and to have a decent definition of done. This article explores why some stories don’t fit this mold and what you can do about it.

The main causes of bloated stories leading to an inability to estimate them are:

• Stories that cover too much
• Developers that do not have the needed domain knowledge
• Stories that have uncertainty due to dependence on new technology
• Stories that the customer cannot articulate exactly what they want

I find the four S’s helpful in getting stories down to size so that they can be estimated and worked on. The four S’s are:

1. Split
2. Spike
3. Stub
4. Time box

OK, I admit it, there aren’t fours S’s, just three followed by a T. Let’s look at how to apply SSST.

Split

Split is the most obvious tool in the big story weight reduction toolkit. A big story covers too much ground; it has too many special cases. People new to driving development with stories run into this one all the time. The key here is to slice the story up into different scenarios. When stories come in big and vague, split them by coming up with specific demonstrable scenarios.

For example, let’s say you are designing a home automation system. You have the big story, schedule lights. Asking the customer what is included she says:

turn on, off or dim lights, based on day, day of week, weekend, week day, and everyday, at specific times with optional random variability. I want a holiday schedule too, you know to turn on and off the Christmas tree and Christmas lights starting the day after Thanksgiving and going until January 6th.

Oh, she’s good. That’s a mega story, but it breaks easily into these more manageable stories:

1. Schedule a light to turn on, off, or dim level
2. Schedule multiple lights
3. Random variability scheduled light
4. Holiday schedule

If story #1 is still too big, it could be broken down further to deal with each scheduling special case like this:

1. Schedule light-on everyday
2. Schedule light-off Tuesday
3. Schedule light-on weekends
4. Schedule light-on weekdays
5. Schedule light-dim

Big stories like this seem to pop up all the time in embedded development (yeah, other places too). If the whole feature is not there, it is not valuable, so we can’t split it. This is business as usual thinking. Split the big story to increase visibility into the development progress, even if you can’t release it. You will discover work that can be deferred, delayed, or eliminated when you split stories into finer grains.

Spike

A story has too many unknowns, either because of lack of domain knowledge or the technical knowledge needed to implement it. In this case, doing a spike will help. A spike is a time-boxed activity where development takes a deep dive in the technology or domain to better understand how to meet the need. A spike is an experiment. It’s goal is to gain knowledge so that developers can estimate the story. We’re training to mitigate risk associated with unknowns. After the spike is complete, we may discover that the story is still too big and needs to be split, or maybe another spike is needed to dig a bit deeper.

In our home automation system, we need to support X10 devices, as well as other control technologies. One problem, we’ve never done X10 before and have no idea how much work it is. So we introduce an X10 spike, where we do enough investigation and prototyping to see if we can control some X10 device.

Stub

Sometimes part of a story is known and part is a mystery. Can we make progress on light scheduling when we have no idea of how to turn on or off an X10 device? In a word: yes.

It’s time to fake-it and use a stub implementation of the light-controlling code. Test drive the light scheduler right up to the interface that protects the core light scheduler behavior from the specifics of controlling a light. Stub out the code that talks to the X10 devices so you can capture light instructions in test cases. You won’t really have a deployable light scheduler until you figure out X10, but plenty of demonstrable progress in the mean time.

This kind of story requires that your product owner can get used to evaluating story completion by witnessing a story test, a script that shows the system events and responses.

When you choose to fake it with a stub, you are splitting the story. So, add a story to the backlog to keep track of the integration work. For example: Control X10 light.

Oh yeah, once the scheduler is well along, the stub and its interface will provide a specification of what is needed from the X10 device driver. A nice side effect is that you can also insulate your core application from having specific knowledge of X10 when you keep the interface intention revealing (and avoid implementation revealing); that will be a plus when a WiFi (or whatever) light controlling device is added to the system.

Time box

Sometimes you need to try things out. I am working with a game company, and they have the fun factor. They ask “How do you schedule making a game fun?” and tell me “If its not fun, we can’t release it.” Fun is hard to specify. How much fun is enough? Some can never get enough fun. Fun has to be balanced with putting in the less-fun features that must be there to make the game shippable and supportable?

Let’s say we have 25 points of work to get done in this iteration. Five of those points are allocated to making the game’s feature X more fun. The other 20 points are needed to keep the overall release schedule in line with the desired ship date.

We can look at the 5 points allocated to fun as the budget we are allowed to spend on fun in this iteration. That’s about 20% of the overall effort. If its not fun when we have spent the 20%, the product owner will schedule some more fun for an upcoming iteration. If it is really critical that it be fun now, the product owner could decide to push something out of the iteration in favor of improving the fun-factor. Either way we are trying to manage and keep visible, what would otherwise be an open-ended activity.

Generalizing this idea, the customer knows they need something, but until they get it they can’t be sure if it is right. This problem is as old as software development, even older. Probably as old as the first customer/supplier relationship.

Combining the ideas

You can see that these tools are not just used alone. Use them together. Our light scheduling story illustrates the idea of a big story that has well understood parts (when lights should go on and off) and mysterious parts (how the heck does X10 work?). Starting with a single story in the backlog, now you have three: the original story implemented by using a stub; the spike story used to go unravel the mysterious part (story name: Spike X10), and a story to productize what is learned in the spike (story name: Turn on X10 light).

Spike X10, being targeted at an unknown should be time boxed, so that activity does not grow to consume too much time. You might need more time on the mystery, but we should monitor that progress to avoid hidden work and constantly being 80% done.

Turn on X10 light could have a budgetary estimate initially, that gets refined once the spike is completed.

Split, spike, stub and time box are helpful tools to cut big stories down to size.