I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.
I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason, this doesn’t bother my wife, Laura, but it annoys me. So I’d like to replace the dishwasher.
The clothes washer is doing fine, but the dryer isn’t working too well. I think we’ve had it 14 years, and I sometimes have to run the drying cycle three times before clothes are fully dried. So, I’ll probably want to buy a clothes dryer, too. I’ve also lately become irritated by the toaster. It’s great and works well, but bread doesn’t fit. I have to angle the bread, with part sticking out of the toaster – so, I get partially toasted bread. Or, I flip the bread midway and then get the middle of the bread overly toasted. So, add a new toaster to the list.
After all that, a new car might be nice.
What is this list? Well, my personal Things to Buy Backlog, of course. It’s a prioritized sequenced list of things I plan to buy. To facilitate long-term planning it includes everything I plan to buy for the next 12 months:
- Groceries
- Tickets to movies that haven’t been released yet
- A magazine that I’ll buy in Newark airport next October because I’ll find a cover story intriguing
- A new pair of shoes
- Big-screen plasma TV
- Home theater amplifier
- Dishwasher
- Clothes dryer
- Toaster
- Car
Don’t you have a list like this, with that level of detail? Of course not. Neither do I. We don’t make lists like this because such a list is unnecessary. In everyday life, we don’t map out the equivalent of a product backlog.
Instead, we make our purchase decisions in a much simpler fashion: “Now” or “not now.” Do I want that big television now, or not now? And this amount of prioritization is good enough.
In many cases, it is also good enough for our product development projects.
Sure, you’ll always need to know what you’re going to build this sprint. But what you build next sprint will likely depend on what the team delivers this sprint, and on how customers respond to it.
That means you might want to forgo prioritizing any further ahead unless you are in an environment that requires it, such as contract development.
Prioritizing features in a “now/not now” manner streamlines your planning process, allows learning to be incorporated into the planning process, and better matches how we prioritize outside the workplace.
Many projects will find this a very valuable shift.
In this post I write about how to do this within the context of establishing a longer-term vision for a product.
