Reduce scope at different scales

Simon Hurry

As a product manager, you risk drowning in backlog prioritisation overload, comparing the relative value of features you’ll never see built. To avoid this fate, you need to continuously reduce scope. That solves the first of two backlog inundation problems:

1. ‘scope entropy’ - it never stops
2. more than one kind of scope.

To tackle the second - different kinds of scope reduction, consider product development opportunities at multiple scales.

Reduce scope on multiple levels

In cooking, you don’t add salt all at once. If you do, you’ll end up with a salty sauce with bland vegetables, and unsalted pasta, which Italians find unacceptable. Similarly, refine scope at different steps, so you end up with a well-seasoned product.

In product development, you have the opportunity to reduce scope during many activities:

1. long-term roadmapping
2. quarterly OKR planning
3. short-term development backlog refinement
4. user story mapping
5. design exploration (with wireframes and mock-ups)
6. writing user stories
7. setting acceptance criteria
8. coding - where you discover more edge cases

At the larger scales - longer time horizons - you choose which business opportunities to address first. At the smaller scales, you make more fine-grained decisions about which edge cases to not support, in favour of earlier feedback, for example. Each of these activities affords a different kind of scope reduction.

Split short-term tasks

Imagine discussing an upcoming feature to display 10-20 items in a list, when someone asks, what if the list contains thousands of entries? This would cause low performance and poor usability, because the back-end and user-interface design don’t expect it, so you decide to descope. Initially, you’ll support up to 100 items, and plan separate work for supporting hundreds or thousands of entries, so development can proceed while you figure out if and when you need to support long lists.

When you work on a single user story, you can always find ways to split the work. Even if you still expect to need the whole story, the two parts don’t generally have equal value and equal urgency (equal cost of delay). This kind of splitting reduces the scope in the short term - even if only for a matter of days - so you can unblock development, and work more efficiently by taking smaller steps.

Focus on one part of each long-term goal

When you plan long-term initiatives, you don’t have to split them in the same way. When you start with a long-term goal on a three-year roadmap, you can choose which part of it to slice off in the first year, without planning the remaining slices for years two and three.

Instead of splitting something in two, and dealing with both parts, as in a game of Asteroids, work across time scales. John Cutler describes this in his system of 1s and 3s.

Choose opportunities to ignore

Finally, use slicing for more than just incremental development. When you slice off part of a large opportunity it helps you focus on a manageable first step, but also gives you an opportunity to decide what your product won’t do. Choosing what to ignore also gives focus to your entire product vision.