Scrum teams and their JIRA Backlog.

Analysts and their Functional Requirements.

The whole is greater than the sum of its parts. Yet we tackle software development by spelling out a list of all the stuff it needs to do. We miss the essentials by doing that.

Scope gets this magical aura. As if it’s important. It’s almost as if chipping away at the to-do list is the purpose of the team! Of course, it isn’t.

We learn in Project Manager School that the PM has three dials to play with: scope, resources and timing. When one goes up, the other two need to go down or the amplifier will explode. The Iron Triangle does not go to eleven.

Fred Brooks taught us that we best stay clear of the “resources” dial.

Postponing releases is an unpopular option either. We make the feedback loop longer. The further away, the vaguer our planning gets. We want to get things done.

So, that leaves us with the best option: build less. Cut scope.

We can always cut scope. We can always come up with smart approaches to eliminate some of the features. We can even decide to throw away the entire backlog.

There is one exception.

The only reason you can’t cut scope is that somebody promised more than you could deliver. That will not be fixed by adding a few sprints or devs to the mix either.

You’ll need to manage your stakeholders. You’ll need to explain to them why they will be getting less.

That’s hard. But then again: management is not easy.