I was speaking to a colleague recently about how her teams were getting on, and she said, “I’m pleased that we’re talking more about prioritising a backlog, much less about what’s in scope. That’s really good.” And it is good news. It shows that the teams are thinking much less about a single large edifice of work that has to be delivered, and much more about breaking it down into small units that can deliver value incrementally over time.

And to relate this to a recent favourite topic, it’s also a great example of avoiding black and white thinking. (See [1], [2], [3], [4] and [5].) If we think about scope we think about what’s in and out of scope, and we tie ourselves to a binary goal: either we deliver the scope, or we don’t. Either we succeed or we fail. And as is the nature of these things we’re more likely than not to fail. Or to avoid that we’ll set our goal to be unaspirationally low.

By contrast, if we turn our delivery into a product backlog it becomes not a case of will we/won’t we, but rather “how much”. Ideally we’ll also be able to ensure the user stories that make up that product backlog are fairly independent. That gives us a lot of flexibility over the order in which we deliver them. We can deliver more value sooner, and respond to feedback more effectively.

Switching thinking from scope to backlog is tricky, though. It takes imagination, and maybe a little help, but it gets easier with practice.

Photo by timlewisnm