We’ve all had the conversation…you’re working at your desk, just finished a call with a customer or prospect, and that random person comes around and taps you on the shoulder…
“Where’s my feature?”
“Huh? What feature?”
“You know — the feature you talked about last week.”
“Oh, that one! It’s on the backlog.”
“I know, so when is it coming out?”
“Well, it’s…on the backlog.”
“Yes, I know. So I told our biggest customer they’d have it next month, that’s cool, right? It’s on the backlog, after all!”
“YOU DID WHAT!?!?”
…and so it goes, and you wind up randomizing the teams to deliver what’s been promised, tossing out a good chunk of strategic work that you’d planned on doing.
Unfortunately, it’s kind of your fault. You see, outside of the development and PM world, the “backlog” is often seen as a commitment. Think about it from the old waterfall approach – you’ve spec’d it, you’ve defined it, and you’ve told everyone that it will get done. And, because Agile is so great, that means that everything on the backlog’s going to get done! It’s MAGIC!™.
I wish I could tell you that this is one of those social problems, that you can just manage expectations by explaining how the backlog works, why it’s prioritized, how the most important things float to the top, and that’s where the teams take their next work from. After all, that’s how Agile works, right — and that’s where the benefits come from, you can be flexible with the backlog and work on what’s most important at the time you need more work.
And that is where all your efforts will fail — that flexibility is all that anyone outside of development and product management ever hears, and unfortunately for us, they try to use that one lever to their advantage whenever and wherever they can. They see something on the backlog, which is important to them, and they infer that it must be the most important thing, so obviously it’s going to be the next thing worked on, so there’s no problem in telling a customer they’ll have it in a month — after all, you’ve got 2-week sprints, right?
While explaining the backlog process over and over again might at some point start to shed light into the eternal darkness, there’s one far better tool for ensuring that these kinds of assumptions and commitments aren’t made outside of your purview. And it’s a very, very simple one:
No backlog is longer than 10 items. Anything that’s not in that top ten list of priorities is not considered “on the backlog.” Call it whatever you want — feature requests, long-term projects, back-back-backlog, the black hole of ideas — but don’t call it the backlog.
10 items. That’s it. And anything that goes on that list has to bump something else off — it’s reasonably easy to manage expectations around those 10 items, and when you put the onus on the people who want to make promises to their clients, it’s amazing how often they demur to the list that’s right in front of them, and still manage to close the deal or make the customer happy.
10 items. No more, no less. Then you never have to have another “Well, it’s on the backlog conversation” again!
