Agile Backlogs: You’re Splitting Your Stories Wrong

A picture of a backhoe and an operator, as if he were working Agile Backlogs splitting stories

Working Agile backlogs shouldn't be something that requires heavy equipment, but it does require discipline and clear thinking.

Why is it that so many Agile Backlogs are impenetrable and impossible to regularly size and prioritize? For many teams, the first sprint or two was the only time they ever really looked at the entire backlog and were able to keep it all in their head. By the time they really get to know the problem domain, in other words by the time they really get a great handle on being able to relatively-size the stories and talk about making things run a lot faster, the backlog is so out of control that nobody has time (or wants) to wrestle it back under control.

For many if not most teams, the backlog is an impediment.

The biggest reason by far is premature optimization: people are just not happy with big, fuzzy user story titles like “do stuff.” It makes them want to cringe. How can a backlog with only ten items on it be worth the million bucks we’re spending on this team over the next year? There has to be more on there than just a few items! Let’s split them up to make sure people understand how much work we have to do.

This, and other behaviors like it, come from a failure to really understand what an Agile backlog is. An Agile backlog is a symbolic work queue. It is not a to-do list (although if you put a gun to my head I’d grudgingly acknowledge that in extreme cases it might be), and it’s not a set of requirements. It’s just a bunch of easy-to-remember-and-use tokens representing work that needs to be done. Usually that work is in the form of future system behavior. Why? Because beginning to describe future behavior is the same as beginning to describe a test. “In the future, when the customer calls, as a sales representative I need a detailed account history so that I can begin an intelligent conversation with the customer right away” But heck, “Get Account History” is perfectly fine for a few sprints — as long as you understand enough to make a guess about relative story sizes. Just because your stories are going to end up in some form doesn’t mean you should make them that way today. Do everything at the last responsible moment. Never a minute before — or a minute later.

But even when people wait until the last minute, and even when they understand that stories are about future system behavior, backlogs still get trashed.

Ways Teams Split Stories in Their Agile Backlogs Wrong

  • Large to-do items clutter the works. When the team needs to take a week to assist testing in setting up 300 test machines, that’s something that provides business value but isn’t a future behavior of the system. To-dos are notoriously bad. Who has had an item like “fix database field old-account-number in table customer-account” on their backlog? We all have. But they’re evil. A better story would be “When the user goes to their customer details page, they see their old account number”. Fight for testable chunks of work. Without a test, you cannot size a story.

  • Failure to break up stories when they leave the team. If you have the same five stories on the storyboard over three sprints because you are waiting on an external group for something, you don’t have a storyboard. You have a waiting-around board, where stories wait around. Instead, at the last moment, when choosing stories for the upcoming sprint, split them into the part you can deliver and the part you can’t start on until the other team gets back to you. Then in your project backlog color these stories and put them at the top to indicate a block. (or split out a new kanban lane) Remember to keep things testable — the story should always describe the test.

  • Breaking up too many stories as they leave the team. If you end up with 30 split stories all waiting on some other group, you also have a problem. Your product owner should have noticed this and fixed it by now. In either case, you have stories on your backlog that you cannot finish. And they are accumulating rapidly. Your sizing for these stories should increase over time. After all, it’s getting more and more unlikely that you will easily finish them, even if they are trivial to code. The release plan, which should be going up the chain of command, should show the project totally out of whack [insert long discussion here about the importance of keeping live release plans.]

  • Sequencing Fever. This begins when somebody says “Well in order to do this story we have to do that one first, so how do we sequence them?” This is a very reasonable request, but it confuses an Agile backlog with a design document. Yes, you need to track dependencies, just like you may need to track requirements. But the backlog isn’t the place for them. The Agile backlog is the place where the Product Owner tracks little symbols of future system behavior that he thinks have business value. Each story is sized as if any outstanding work required for that story will be completed with the story. If your team is doing anything of any importance at all you’re going to have other docs you are reading and updating as you go along. These docs and that work doesn’t go away simply because you’re on an Agile team! And once you begin sequencing, once you get confused about what exactly are the criteria for backlog items, it’s Katy bar the door. Don’t do that.

  • McDonald’s Agile Backlogs. This is where the team sits passively while the Product Owner brings forth the backlog as if he were returning from the mountain with the Ten Commandments. In this scenario, the team is always just asking simple questions, as if they’re only job is to take an order, like somebody at McDonalds. Backlogs easily get of of control in this scenario, because the team (including the Product Owner) isn’t really managing them. Remember that while you are not doing a Big Design Up Front (BDUF), you should still understand and be able to mentally digest the backlog. There’s another long discussion here, but just look at it this way: if the backlog is full of items that are too numerous for you to remember, too vague for you to size, and too far out in the future for you to care about, then why have an Agile backlog at all? What would be the point in release planning or any of the other activities that require looking at the entire backlog? You’re Kanban. Nothing wrong with that. Just be honest about it and move on.

Remember Agile Backlogs Are Never Perfect

To some degree, backlogs are always going to be disorganized. You are always fighting chaos. That’s why it’s so important to keep their size small — taking an hour and reviewing the backlog, sizing and prioritizing the entire remaining items, should probably be done each sprint. In fact, it wouldn’t hurt to start from scratch. Throw away the old stories (or hide them) and have the team restate what is left and get it organized, just as if you were on day one of the project. That way you’re constantly trying to re-state the backlog in terms that are simpler. (This restating the backlog was brought up in my book about being a kick-ass ScrumMaster.)

If you’ve followed along so far and would like to continue the conversation, check out the associated Agile Backlogs book.

Follow the author on Twitter

March 13, 2012

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy this password:

* Type or paste password here:

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>