Continuously reduce scope

Tania Melnyczuk

A few months ago, a developer called me a ‘good product manager’ because I reduce scope. I’ll take the compliment, because along with the rest of product management, reducing scope provides a critical enabling constraint. In fact, compared to all the other gross oversimplifications, you could do worse than describe product management as continuous scope reduction. This article explores what that means.

Why reduce scope

In software development, building everything you can think of sounds appealing, but several factors conspire against it:

1. software development’s eye-watering expense
2. overly-complex software’s terrible usability
3. everyone having a different opinion about what any given software lacks
4. how features often don’t living up to their initial promise.

Even with good validation and design, a product team can usually generate good ideas several orders of magnitude more quickly than they can build them. Meanwhile, scope seems to expand all by itself every time you learn more about the details of any problem you work on.

Maximise the work not done

A naive prioritisation approach captures every idea in a backlog, and determines its priority order. You might prioritise product capabilities and improvements based on their return on investment, various kinds of risk, and alignment with your product strategy, for example. This still tends to give you more development work than you can handle: for every good idea that will benefit your customer or customers, ten more want your attention too.

Effective prioritisation requires more than finding something important to work on; opportunity costs mean choosing the most important opportunities instead of trying to do everything. If you don’t work constantly to maximise the work not done, the weight of an ever-growing backlog will inevitably crush your hopes and your dreams. Reduce scope, because your everyday happiness depends on it.

You can always split a user story

I like to imagine a fundamental theorem of agile software development that goes like this:

Theorem: you can always split a user story into two smaller worthwhile pieces of work.

It wouldn’t matter if the two smaller parts together require more total effort than the original work, because you might not have to do both. Take care not to end up with half a mug (photo), though; an undecorated mug works better. If you find it difficult to split user stories, remember that you can practice.

Most objections to the claim (not really a theorem) that you can split a story precede actually attempting to do so. Therefore:

Corollary: you can’t split a user story without actually trying.

If you lack story-splitting inspiration, you can use a brute-force attack: try one of the many approaches included in The Humanizing Work Guide to Splitting User Stories, whose story splitting flow chart includes nine story-splitting patterns.

Don’t just split stories

Splitting user stories and then not implementing all of them helps, but ultimately delivers too little scope reduction, too late. To avoid drowning in user stories, split work at a higher level.

Split epics, roadmap features, quarterly objectives, long-term initiatives, and everything else all the way up to your minimal product definition. As well as continuously reducing scope, reduce scope at multiple levels.