In the Asteroids game, you have to be very careful about which asteroids you shoot because you can’t put split asteroids back together once they’re broken. But you can put split stories back together.

To avoid a backlog filled with lots of tiny stories, take a bundle of stories that go together, and write all their titles on a single card as a bulleted list. Summarize those titles with a single title on your new card. Voilà, you’ve got one big story.

This is pretty fantastic stuff when you think about it. The card, and the title written on it, is a tangible handle to lots of intangible ideas. Ideas are a lot more malleable than rocks or heavy documents. We sometimes forget that another name for software development is knowledge work. When we forget that and instead fixate on documents and process, it turns into something dry and secretarial. And when I work with people managing huge backlogs filled with tiny stories, it feels horribly secretarial.

Bundle Small Stories to Clean Up Your Backlog

I often run into product teams that have backlogs with hundreds of items in them. And, predictably, they tell me that they struggle to prioritize their backlogs. When I look into their backlogs, they’re often filled with lots of little stories. Talking about each one of them to make a prioritization decision would take hours, or days in some cases. So don’t.

If this were Asteroids, you’d have lost. But since it’s not, try bundling up your small stories into bigger stories:

1. If your stories are in an electronic backlog, get them out onto cards or sticky notes. Whatever tool you’re using should be able to print or export to a spreadsheet. I’ll use a simple mail merge in a word processing program to create labels for all the stories and then stick them to a card, or print directly onto cards.
2. Ask for help from a group of team members who understand the system. Schedule a room with lots of wall or table space where you can work.
3. Give everyone a handful of story cards and ask them to start placing them on the tabletop or sticking them to the wall.
4. When you see a card that seems similar to one you’re placing, cluster them together. Don’t think too hard about what “similar” means—just go with your gut.
5. Do this organizing in silence, at least to start. You’ll find that it’s the conversation that slows things down. And it’s good to learn to use the model and your body language to communicate.
6. Move and reorganize any card you want. It’s everyone’s model, so that means no one owns the position of a card. If something looks out of place, move it. If someone disagrees, he or she will move it back. That’s your cue to discuss why.
7. After things settle into clusters, take a different color card or sticky and make a header for each cluster. On that card, write a better story name—one that distills why all these cards are similar. If you’ve written a distillation called “UI improvements,” that may be too vague. “Improve entering and editing comments” would be better, assuming those UI changes were about comments.
8. The distillations become your new, bigger stories. The other cards become bullet points in its description. Add those distillations back into your release backlog. Or, if they’re deferrable, move them all the way back to your opportunity backlog.

This works fantastically well for deep backlogs composed of lots of little items. It’s wonderful for deep bug lists, too. You know how there are always lots of lower-priority bugs that never get fixed? Bundle them with other higher-priority bugs in the same area of the system. When a developer goes in to fix the high-priority bugs, it’s often trivial to hit the low-priority bugs, too. Your customers and users will thank you for it.

I often hear from people trying to figure out this story mapping stuff that it’s just “too much.” When I ask them “What went wrong?” they’ll tell me about creating a very large map of their whole system in order to discuss a simple feature. They’re right: that’s too much. So don’t do that.

Map only what you need to tell a story about your feature.

For example, I was working with a company making some changes to the commenting feature in its collaborative document editing software. The team mapped document editing at a high level, and they only used a few cards for that. When they got to the area for commenting, they added more cards that summarized what their product did today using lots of bullets on a single card. Then they began to discuss changes they’d like to make, adding lots more cards for all the details and options they were considering.

When adding a feature into an existing product, map a little ahead of where the feature begins in your users’ story, and a little beyond where it ends. Don’t map your whole product.

Remember that story maps support conversations about your users and your product ideas. A good rule of thumb is this: if you don’t need to discuss it, you don’t need to map it.

I’ve described this whole rock-breaking journey, and even cautioned you to treat those rocks like asteroids in the old Atari game so you’re not tempted to break them down too fast. Hidden within all these strategies is the assumption that a lot of the stories we come up with are big. But, actually, a lot of them aren’t. After you deliver a product or feature to users, you’ll immediately find lots of little things that are dead obvious—things you wished you’d have thought of before shipping, but you didn’t. At least that’s what happens to me. For those things I don’t have an opportunity discussion, or pull together a group to do product discovery, because it’d be obvious to everyone they should be done. For those things, I’ll get them into a current release backlog and then as early as possible workshop them with team members so we can get them built. The same goes for bugs, and lots of little improvements.

Saving the World, One Little Fix at a Time

Here’s my friend Sherif from Atlassian again. He was explaining to me that product team members pick up and work on lots of small fixes and improvements all the time. They worry about their users a lot there. And they know that lots of little bugs and imperfections drive their users crazy—and that drives them crazy. They say it’s like dying a “death by a thousand paper cuts.” So, on the wall near a team working on a product called Green Hopper is a bunch of tick marks. Every time a team member fixes one of these little things, he or she makes a mark on the wall. It looks like 47 of these little fixes will go out in the next release. If you use Confluence or JIRA, you can thank them later.