Building a product is an exercise in managing expectations. We gather ideas and turn them into a gadget that solves problems. These ideas can come from everywhere. — team members, customers, competitors — you name it. Even a small team with a single customer can generate an infinite stream of new ideas. Ideas are the cheapest renewable resource on the planet. They might be trivial, but ideas are not free. They come at the price of expectations.
In the old days of projects and Work Breakdown Structures, each requirement had a price. Building that Sales Report would cost €22500, and each project started with heated debates. Is this feature really necessary? Can we afford this? Can we simplify it or cut it altogether? The Requirements Gathering Phase forced us to throw away most ideas as they didn’t fit the budget. Only then did the project get greenlit.
The Gantt chart managed expectations by answering the stakeholders’ two most important questions:
- Will I get feature X?
- When will I get feature X?
These days we no longer plan the scope of projects upfront. We’re incremental and iterative now, discovering our product as we go. That’s powerful, but as a result, we have gotten terrible at throwing away ideas. We collect, refine, enrich, groom, shape, research, design, split, analyze and tweak potential features, but we never seem to throw one away. We no longer care about Scope Creep because our very notion of scope has changed.
We no longer see software development through the lens of scope. Instead, we now think of development capacity as bandwidth. We have a team that can deliver 24 Story Points every sprint. Forever. We don’t think about cutting scope anymore; we think about prioritization. We look at the next things we want to build and rank all other ideas lower on the backlog.
Since we have an almost infinite stream, we no longer care whether we will build something. We look at our limited bandwidth and only care about what we will build next. Instead of throwing away ideas, we push them back indefinitely. The hard No has been replaced with the weasely “maybe later“.
While that looks great on paper, there’s a catch: Prioritization is a lousy way of managing expectations.
When someone adds an idea to the backlog, they are not just adding a potential feature. They are emotionally invested in their idea. While they understand that other features might take precedence, they still care about it. Reshuffling the backlog for the seventh time isn’t going to change the fact that they expect it to get built eventually.
That’s why deleting Jira tickets is so hard: somebody cares about them.
It’s why MoSCoW analysis is such a flawed approach. Almost everything is somebody’s baby and, therefore, Must Have.
The plan is our primary tool for managing the expectations of everyone involved with the product. Developers look at it and know what to build next. Stakeholders see when they can expect that highly anticipated feature. Everything that’s on the plan carries an expectation. I might be disappointed if I don’t see a ticket for my beloved Sales Report. I might even try to reopen the debate. But what I’m not going to do is somehow expect that it gets delivered anyway. What’s on the plan is a promise. What’s not on the plan won’t get done.
We can hold Backlog Grooming Sessions for ages, but at a certain point, that stakeholder will complain that their story has been pushed back for months. “We’ve been asking for this since last year!” — It’s better for all to kill that story early.
We can try to sidestep the big question by replacing our roadmap with Now/Next/Later. That won’t keep stakeholders from having a delivery date in mind. Better make it explicit to avoid frustration.
That’s why we must return to the hard No’s and only plan those things we’re really going to build. We need to confront these differences in expectations head-on instead of weaseling out with “not now, maybe later“. Good plans might hurt in the short term, but make expectations crystal clear. A great plan makes the implicit explicit.
Prioritization theatre is an enabler for weak planning. It encourages us to postpone rather than decide. It asks us to pretend people are rational actors. That’s rarely the case. It sweeps stakeholders’ two most pressing questions under the rug and lets us pretend they don’t matter.
When we start making explicit plans, we notice there is no need for prioritization theatre. We don’t need to groom backlogs and shuffle Jira tickets. That won’t help us decide. We say Yes to what we will build and a hard No to everything else.
What’s on the plan gets done. What’s not, won’t.