Random Island off Costa Rica / Paul Gambill

(If you’re in Seattle, I teach a monthly introductory class on Agile project management that covers this topic of backlong rank-ordering in detail. You can see the latest upcoming class schedule here: https://generalassemb.ly/instructors/paul-gambill/6046)

Walls Before the Roof

How backlog rank-ordering delivers higher value in a shorter time.

Only a few hours after stepping onto the sailboat for a peaceful, sunset cruise on the Pacific side of Costa Rica, we ran into problems. The sky darkened. The waves became choppier. Rain fell lightly at first, but soon exploded into a shower of warm pellets.

We didn’t see a sunset. The clouds closed in around us, and visibility was reduced to 100 feet. Then the lightning came. Thunder peals clapped every 30 seconds. As I huddled with the rest of the passengers in the only covered area of the boat, I watched the captain do his best to steer us away from the bay and into safer waters further from shore. As I looked up at him, the roof of the boat suddenly and dramatically changed. Like Schrödinger’s cat, it existed in simultaneous states, but now observation said it wasn’t there. A bolt of lightning had hit the boat and torn away half of the already minimal overhead protection.

As the mom of the family from Long Island became frantic over not wearing a life jacket, I drank a rum punch. The ex-pat children on board did their best to translate the reassurances from the crew to the nervous New Yorkers. Then finally, after a few hours, the sea calmed.

We took the boat into the bay, anchored it, and all clambered into the dinghy that would take us to dry land. Our return to shore was marked by fallen trees, washed up debris, and a noticeable lack of people. But we were safely ashore, and it was time to get a hamburger.

What if circumstances on that trip had gone in a different direction? What if the captain hadn’t been cool under pressure, and we had ended up on that island pictured at the top in our own three hour tour? How would we have reacted and determined what we should do to protect ourselves?

Survival Priorities

• Shelter
• Water
• Food
• Fire

Let’s assume you have crashed your boat on a remote island. After the initial panic, you and your group have realized that there is a lot of preparation needed before you can weather out that storm that is coming in the next day. You all agree that those four things are important and need to be taken care of, but you have limited time to work and you disagree on which of the four are most important.

Is it fire, so you can keep warm, cook food, boil water, or make a signal for rescue?

Is it water, so that you don’t dehydrate trying to built a shelter and get rescued?

Is it food, so that you can keep your energy up as you work to protect yourselves?

Is it shelter, so that you can do all this work under cover, without rain soaking your clothes, making you cold, and possibly causing illness?

There are valid and convincing arguments for each of the four, but you only have a short time to prepare. Would you rather spend your time debating the merits of your argument with your compatriots, and only afterward decide how exactly you’re going to meet one of those priorities? Or would you rather get achievable things done first that deliver the most value, using your time as wisely and efficiently as possible?

Software companies end up in this scenario all the time. As the project schedule marches ever closer to the deadline, debates rage:

• Is this bug a Priority 1 or Priority 2? Major or minor?
• Can we cut this VP’s pet feature that is part of a larger “social” initiative in the company?
• Do we add this bug to the official bug tracker, where project managers will see it and freak out, or do we maintain a separate list of bugs that management doesn’t need to know about?

All of these problems go away or are minimized with the introduction of two simple things:

1. A rank-ordered backlog of tasks, where the first item delivers the most relative business value to stakeholders, and the last item delivers the least relative value.
2. A product owner, or stakeholder, who is responsible for maintaining the order of items in that backlog.

You might ask: why not order by priority? All the P1 bugs have to get done anyway, so what difference does it make?

Let’s return to the survival scenario, and focus on what it takes to build a shelter. To start, here is how the shelter work might be prioritized:

1. Roof
2. Walls
3. Foundation
4. Door

The roof is the most important aspect. It’s there to keep the rain off you, your clothes and food dry, and protect a fire from washing out. But, even though it’s the top priority, how are you going to build the roof first?

Now let’s look at a backlog ordering that reflects the way the work will actually be done, by delivering the most value up front:

1. Foundation
2. Walls
3. Roof
4. Door

You do the second task after the first task is done, the third task after the second is done, and the fourth task after the third is done. And now you have a usable shelter.

Software works the same way. You can’t build a working login screen until your back-end authentication is working. That’s just the reality of it.

So why spend unnecessary time and resources debating the minutiae of priorities? With a stakeholder (or, as is more common, a group of stakeholders) setting the backlog order, there should be no confusion as to what the team works on next.

If your company suffers from these problems, there are some easy steps you can take without necessitating an entire Agile transformation:

1. First, organize your work into a backlog. You likely already have a bug tracker and a feature tracker, and if you’re lucky, they’re in the same system. The point is to make an artifact for every piece of work you have, even if that means sticky notes on a wall or printing out a piece of paper for each task.
2. Second, get someone to order it. In the absence of a truly involved business stakeholder, have your project manager do it. There’s definitely someone on your team who has the best understanding of the high-level business requirements. Force them to list out each task artifact in order. No ties or spot-sharing allowed. Bugs and features hold equal weight in a backlog, but it’s up to the person ordering it to determine where they fall in the ordered list.
3. Do the work. Take the top item first, and work on it until it’s done. Then take the second item. Repeat until your stakeholders are satisfied with the product and you’ve met your deadlines.

Backlog rank-ordering is a reflection of reality and how the work is actually going to get done. By being honest with ourselves on what the process is actually for (to get the work done!), we can use it to our advantage. We can skip past the endless debates, stop wasting time on work that isn’t necessary, and focus on getting as much value as possible delivered within our constraints of budget and schedule. You’ll be much happier in your work, and the stakeholders and users will be happier with the resulting product.