Skip to content

It is usually more productive to talk about feature scope than about priorities. While slight shifts in priority are seldom actionable, scoping requires decisions. Scoping scales products by their amount of features, and not by overall quality. Tradeoffs must be made and features must be cut — at every level of the stack.

The first step in scoping features is to get everyone on the same page. For this, words are often not enough. A shared understanding is better achieved through detailed sketches and interactive mockups. Too much code is written based on a false assumption of agreement. Make a feature obvious, then decide its scope.

The next step is to decide on which features to keep and which features to cut. Scoping is about tradeoffs. Each potential feature has an expected cost, utility, and interplay with other features. These tradeoffs should be difficult as they decide what the product will be. And iteration does not preclude planning.

When features are fleshed out and scoped in it is finally time to build. At this point there should be no fundamental questions unanswered or important thoughts unsaid. If there are split opinions it is time to disagree and commit. Any feature of uncertain scope should be pushed for re-planning in the next iteration. Plan more, code less, and always know where you’re going.

—   ¶