How you’ll probably learn to split features

6 years ago

I originally wrote this article in 2006. I have written a little more on this topic in Three Steps to a Useful Minimal Feature. These days I tend to use the terms story and feature interchangeably. I apologise for the confusion that this might create. Wherever necessary, substitute the term you prefer.

Most user stories are too big—at least, this is how it tends to be for teams making the transition to incremental development and delivery. After discussing the benefits of splitting stories into manageable increments, a team generally goes through (at least) these stages of development:

  1. splitting stories along process lines, then
  2. splitting stories along architectural lines, then
  3. splitting stories along procedural lines, then finally
  4. splitting stories into smaller stories

What’s the difference? Allow me to explain with an example from my own work.

I used to write software to collect registrations for a conference series called “XP Day North America”. I had grand visions of running the conference several times per year in several locations around North America, and I knew I wanted to make it as easy as possible for people to register. Why? I needed their money to fund organising the events. Eventually I wanted the system to provide conference content, let people sign up to hear about more events, and all those good, standard web marketing features, but I needed an income stream, and I needed to turn it on as soon as I could. This encouraged me to focus on the shortest path to my potential registrants’ money, which led me to choose the feature collect registrations.

Since “collect registrations” sounds more like a theme than a feature, I split it into coarse-grained stories, like these—

  • anyone can register by paying immediately with paypal.com
  • anyone can register, then request an invoice
  • anyone can register (and pay for) an entire group, rather than just themselves
  • anyone can register and pay later
  • automatically generate the invoice
  • remind all unpaid registrants on demand
  • automatically remind unpaid registrants on a regular basis
  • a registrant can cancel his registration
  • a registrant can add or remove people from the group

Now these might not seem coarse-grained, but when your iterations are on the order of a half-day each, it’s nice to have stories that I can complete in about an hour. (Yes, an hour.) Since I am also the Product Director on this project, and my primary goal is to be able to collect money from registrants, I identified the first story as the minimum for the first release, and estimated it at about 2 hours. That’s a little big for a 3-hour iteration, so I want to split it. The first thing I did was a little modeling, to make sure I knew what I meant by “anyone can register by paying immediately with paypal.com”.

Stepping into the shoes of the teams I work with, here is what I often see when we try to split the story anyone can register and pay immediately with paypal.com. First, the split along process lines:

  1. design
  2. code
  3. write programmer tests
  4. write acceptance tests
  5. document

Splitting stories along process lines delays delivery. It provides a fine checklist, which could help as a mini-plan for the story, but none of these items produces value on its own. The closest, perhaps, is “write acceptance tests”, but even those don’t represent value until someone has tried to test-drive with them, because only then do we learn what we missed and what we mis-wrote. A team generally does this in their first planning session after deciding to “go agile”. It’s a good effort, but it does nothing to encourage them to change the way they work. It is certainly not incremental. When we apply the INVEST test, this split of stories mostly fails. While these “stories” are perhaps negotiable and somewhat estimatable (estimable? neither seems correct), they depend on one another, have little inherent value on their own, are likely not all small and are definitely not all testable. We need to try again.

Once the team gets past this troubling first phase, they tend to split across architectural lines:

  1. test-drive the UI
  2. test-drive the business logic
  3. test-drive the database client
  4. write acceptance tests
  5. document

Now this is an interesting hybrid approach between architectural and process-based splitting. This looks more like a traditional work breakdown structure, which appears to allow for concurrent work, but doesn’t. (Can you see why?) It is tempting to say that this split satisfies the independent property of INVEST, but it really doesn’t, as you would find out as soon as you tried to integrate the work of the individuals who performed each task independently. There is still no value in just the UI or just the database client, the items are smaller, but probably not small enough, and as a result, I would not trust any estimates on them. We need to try again.

Once the team gets past this second phase, they tend to split across procedural lines:

  1. collect registrant information
  2. integrate paypal.com
  3. e-mail registrant after payment
  4. e-mail organizer after payment

This is much better, because at least we no longer see “write acceptance tests” and “document” as separate tasks. These are almost stories, as they are self-contained bundles of work that include “code, design, programmer tests, customer tests, document, deploy, install” and all those wonderful things. There is still one big problem: this split of “stories” fails the “V” property: just how valuable is collecting registrant information? We certainly can’t deliver that on its own. We need to try again.

After the team gets past this third phase, which tends to last a while, they finally get it, and split the stories into self-contained increments of value:

  1. register with just e-mail, then pay with paypal.com
  2. collect more information from registrant (name, address, phone)
  3. notify both registrant and organizer after registration

That’s it! This story split satisfies all the INVEST properties—

Independent. It is relatively easy to see how to build each of these stories on its own. #1 is a one-field form whose submit action includes going to paypal.com; #2 is a multiple-field form with a simple “create” submit action; #3 is a one-field form whose submit action sends out an e-mail to two recipients. We can build these in any order.

Negotiable. We can negotiate the scope of each of these stories. For #1, is it just a link to paypal.com, or do we have to bring the user back to xpday.info? Do we have to handle an incomplete payment, or will humans verify that by looking at the list of registrants and the payers in their paypal.com account? For #2, how much information do we have to collect? For #3, do we send out a standard e-mail? Is it a form e-mail with some user-based personalization? Do we need a tool for writing or changing the e-mail template? For each story, we can easily negotiate economy or luxury versions.

Valuable. If we do #1 on its own, then at least we can take their money and we have enough information to contact them after they register. We can easily choose to do #2 or #3 in either order after that. Even better, we can do #2 on its own, if “the business” decides that a human requesting payment is good enough, but we really need an automated way to capture registrants’ information. We could even do #3 first: a person could take all the registration information (by phone or e-mail), then enter the registrant’s e-mail address in a form that sends out a form letter to her as well as the organizer. Any of these could have value, depending on the needs of the customer.

Estim(at)able. The first story is the biggest, because I don’t remember how to do the whole paypal.com thing, but I’m pretty sure I can put the bare bones together in 30 minutes. It might take another 30 minutes to handle a return link, and another 30 minutes for the “receiving page” to know whether payment was complete or not. I did this before, but about a year ago. For story #2, we can have something in 15 minutes, then it’s up to the product director to critique the UI layout and suggest changes. For story #3, we can have a standard e-mail in 15 minutes, it’ll take another 30 minutes for a form e-mail, and another 30 minutes to be able to change the e-mail template through the web UI. Make that 90 minutes, because we would have to add role-based security for the first time.

Small. Only one story is 90 minutes; the others are 30 minutes or less. For a 3-hour iteration, we can fit about 4-8 stories into an iteration. According to my good friend Jim Shore, that’s a good number of stories for an iteration, and I agree.

Testable. I would hate to see what someone like Michael Bolton would do with these little stories. I should ask him to test the site, just for laughs. (Well, I think I’d be crying by the end, but he would be laughing.) As a product director, though, I can easily tell when these stories are complete, so I can easily write acceptance tests for them.

So there you have it, I hope: a thorough example of splitting a story into smaller increments, each able to be built and delivered independently. If our plan starts to show that we’re running long, we can cut 2 of the 3 stories, but still meet our primary business objective: collect payments from registrants. That would be good enough for our first release. Now would be a good time to freshen my coffee (during which I have my stand-up meeting with myself), then get to work. We absolutely must have a working first release in the next 3 hours… or at least that’s what the product director claims.

Need Help?

Would you like to learn more techniques like these? Read about Product Sashimi training.

This entry was posted in Featured, Product Sashimi. Bookmark the permalink. -