Hopper vs Roadmap
Ryan Singer has mentioned that Basecamp use “A hopper, not a roadmap” as a way of managing upcoming work.
Here’s his definition:
A collection of ideas about what to do in the future without any order or sequence and without any commitment to doing any of them.
So in contrast, a roadmap (or backlog) is usually:
A list of defined work that is committed to and completed in sequence.
Problems with Roadmaps
- They’re not flexible – the right thing when you planned the work might not be the right thing when you come to tackle the work.
- They’re often order-dependent, which means you can’t drop items if they get stuck.
- There’s a feeling of debt – there’s always a constant stream of work to do before you can even think about working on some other task that recently became important.
Why the Hopper works for Basecamp
Basecamp have lots of other work practices in place so that their system works together.
The key parts that I think allow the Hopper to work for them are that:
- They expect to be done in a cycle; that way items don’t roll over in to the next cycle.
- They have a Strategy team refining the pitches in to well defined concepts ready for product teams to implement; that means you spend less time hitting blockers during the “work” cycle.
- Product teams don’t have any other assignments like dealing with unrelated bugs or support requests that distracts them from the cycle work.
- They’re happy to tweak scope through the cycle so that some version gets shipped at the end.
Moving to a Hopper
In smaller teams where the team is both defining concepts and implementing the work, or where the Hopper idea is failing because you’re lacking some other parts of the system, I think a hybrid approach may help move in the right direction.
We know that Basecamp prune the Hopper to some degree:
Yeah, it’s also not a backlog. I like to use a tile map. There’s only a limited amount of space on each tile so it naturally limits the number of things.
So with that in mind, I visualise the Hopper as a 3 × 2 × 1 grid:
- Items at the top are looser pitches and can be changed freely.
- Items in the middle are having background work done on them to help define the concept.
- The item at the bottom is a clearly defined concept ready to be worked on.
The most important item is the one at the mouth of the Hopper, as this will be the target of the next cycle. Try to carve out a good portion of uninterrupted time to work on this item so that you can be confident that some version of it will get shipped. It can be difficult to do this, as in smaller teams you also need time to keep the business running. I’d aim for between 50-70% allocated for “hopper” work. Start smaller, so that you’re more confident in shipping some version rather than trying to allocate too much time and then running over.
You also need to allocate some time to looking ahead. Aim to allocate enough time during a cycle to look at the item at the mouth of the hopper and clearly define the work that should happen in the next cycle. Try to remove unknowns and define what’s in and out of scope.
Ideally, all work in the hopper should be clearly defined pitches, rather than vague ideas. If they’re not, then spend time during cycles figuring out the details as they get closer and close to the mouth. Feel free to eject them from the hopper if there’s still too much uncertainty, or other more well defined and important items of work come up.
The idea is that you still get a feeling of security about the next 6 blocks of work coming up, but you start to introduce the idea that the items can be changed, and that the next item is clearly defined so that you’re really confident that it will get completed during the cycle.
Items closer to the mouth have a higher cost of change, as more homework has been done on these to refine them in to a workable concept. The homework is still useful even if the item is switched out, but the team will need to re-familiarise with the problem if it gets chosen in a later cycle.