« The Puppies Cometh| Main | Agile Warrior: Breaking up is Hard to do »
Understanding Backlogs
I've never seen people get as wrapped around the axle as people who are new to agile and are creating and managing a backlog.
I'm not a famous author. Nor do I play one on TV. I'm just a coach helping teams get agile and get fast in their delivery of value back to the business. So if you're a fanboy or a hero-worshipper there's lots of better places to go. All I've done is make this work a few dozens times with all kinds of obstacles and problems along the way.
It's been interesting to read about backlogs, however, and I've seen a lot of folks who are over-educated really screw the pooch. (an unfortunate phrase from my Marine past considering my previous post!) In backlogs, in particular, it seems folks are either too theoretical and not practical enough, or "practical" to the point of following a recipe and perfectly fine with filling out forms. If you're in this boat, here's a hint for how your project is going to work out: slow and tedious.
So what's a backlog? How does it fit into a big organization? What's the difference between a user story and a use case? How can teams get chartered effectively without delivering top-down "shall" requirements? How can the organization (not the product owner) make sure teams are doing what they are being paid for without controlling every fine detail? What's a good backlog look like and what's a bad backlog look like?
As usual, let's go to the bullet points. If you have any questions, please comment and I'll be glad to explain.
- At their core, backlogs are just work queues - If you cut away all the theory and the nonsense, all the pundits and the so-called experts, a backlog is just a list of stuff you have to do to get paid (or to make the boss happy). If all else fails, go back to this truth and you'll do fine.
- Backlogs hurt you if they have too many items - This rule is going to hurt, but you have to follow it: You can't have more than 20-40 or so items on your backlog. The brain can only keep so much in your head at the same time. Team meetings must consistently go over the backlog for various reasons. Remember that agile is built on conversations. People need to talk about the backlog informally. Nobody ever had a conversation about the phone book. If your backlog is over 40 or so items -- over the amount that you could easily have a meeting and say, talk about sizes, then you're upside down. Your descriptive powers have overcome your cognitive abilities. Time to have some kind of hierarchy.
- User Stories are deliberately vague - What goes in a backlog? User stories. What's a user story? It's the thing that goes into backlogs.
Now that we've wasted our time with that, just what the heck is the point of user stories? Best I can figure, we don't like any of the other ways of doing requirements so we'll just patch up some new stuff and give it a new name.
It's more than that, of course, but not a lot more. So now that you realize you're going to have to have a two-level backlog for your project, how do you pick the top level? The best way I've seen is to make a phrase that describes the future behavior of the system. Then the stuff underneath that can be all the things you have to do to make that future behavior a reality.
So you'll have some bullet items in verb-phrase noun-phrase format. "Process Claims", "Withdraw Money", "Drive to Grandma's House", "Rob Liquor Store". If you're fancy, you can even start talking about just who is going to be performing this behavior, such as "As an ATM User, I need to Withdraw Money", or "As a Criminal, I need to Rob a Liquor Store"
So create a big list of these future-behaviors in the correct format. Guess what you've got? It's a use-case survey, my friend, the last vestiges of RUP reaching up from the grave to scare the simple-minded and the children of the village.
Did I say we were doing use cases? Nope. Did I say we were doing RUP? Nope. Did I say there is a big bunch of paperwork and meetings waiting on us, we're never going to finish, and now I have to put my resume on Monster? Nope, nope, and nope. We can use parts of other processes. It's okay (holding hand)
- If you're in a big company, you gotta have a goal decomposition strategy - Use case titles and use-case "stuff" gives us a key piece of what we need: a goal decomposition strategy. Guys with suits up in the executive office have big goals. These goals get decomposed and prioritized until finally your project gets the green-light for a small subset of supporting goals. Even in a greenfield (new) project with just a simple customer, isn't it a lot better to talk to the customer about the way the system is supposed to behave in the future than a work queue of stuff that might not make any sense to them? After all, the customer says "I want to be able to do X with the system" and 2 or 3 weeks later you're sitting next to them saying "Here you are, sitting at the system and doing X, right? Isn't that cool?"
So your backlog starts out with a bunch of future-behavior statements that have been decomposed from higher-level goals. It starts out with a use-case survey. (play dramatic music here)
- Apply MDA to goal-based, narrative format requirements - Well if we're going to talk layers of goals and start pulling in stuff from other processes to help us, why not use MDA as way of describing our layers? It's perfect for the chore.
So the hierarchy, from pointy-headed-suit-guy to Java-Joe the coder, goes like this:
- Business Use Cases, Independent Model - What are the generic goals of the business, leaving all computer stuff aside? If you're a grocery store, your goals probably consist of buying goods and reselling them, and all sorts of stuff to support that. It should be an easy list of goals, 20-40 items in total. (those numbers ring a bell?) If you have too many, you're working in the next level
- Business Use Cases, Specific Model - This is how your business actually operates in the real world. Sure you receive stuff at the warehouse, and sure the generic way to do that is pretty much the same all over, but in Europe? Gee, they have all these crazy business rules about how the trucks are supposed to dock, and how long the drivers can wait, etc. "Receive Shipment" is the Independent Model, but there are two Specific Models at the business level "Receive Shipment North America" and "Receive Shipment Europe" This is the stuff your program office or project office should be working with.
- System Use Cases, Independent Model - This is where most teams get started. The Product Owner already knows the business goals he/she is supporting, and they already know the different ways these goals are reached by the business. What they need is a computer system to help them reach these goals.
Just like before, each item at the higher level can have several children. If you think about it, you can see this at work all the time. Your business may have a goal of keeping tracks of prospects, but there might be a dozen computer systems your sales agents use to do this. One agent might use Outlook, another Act!, etc. Each specific business goal can have multiple systems that support/implement it. For each of these systems, there would be various steps you'd have to go through to make it happen. Note that there is no mention of the type of computer language or database -- just the steps you have to go through to reach a certain goal. This is the level for your backlog, and the level for talking to your Product Owner. What steps should I go through as an X do accomplish goal Y?
- Tasks - Tasks are the "under the covers" stuff
