Priority and Scope

A release is a version of a system made available for use. A product may have multiple releases as its requirements change. For this lecture, the initial release is the first version of HopPress made available to its users.

The initial release may not include every requested behavior. The requirements specification must therefore record what is included, deferred, and excluded. This is called prioritization and scoping. Prioritization is the process of deciding which requirements are most important. Scoping is the process of deciding which requirements belong in a particular release, deciding what is “in” and what is “out” of scope.

Scoping can also apply to the entire product or project, deciding what will not be built at all. Failure to make these decisions can lead to scope creep, where the product grows beyond what was originally intended.

For HopPress, we use three categories, ordered by how firm the commitment is. Must have (required for the initial release) and defer to later (not required now, but planned for a future release) are both release-scoping decisions: features HopPress will eventually have, just at different times. Out of scope (not planned for HopPress as we are designing it in this course) is a project-scoping decision: not on HopPress’s roadmap at all.

For example, HopPress must let readers list and open published posts. Authors must be able to sign in, create and edit their own drafts, and submit a draft for review. Editors must be able to publish a submitted draft or return it to the author. Administrators must be able to assign roles. The system must record each post’s author, state, and publication time.

We can defer email notifications and reader comments to a later release. They would be useful, but the initial release can work without them.

WordPress-style plugins and themes, analytics, real-time coauthoring, and a public API for outside applications are out of scope. Unlike email notifications and reader comments, they are not on a path to a later release; HopPress is not currently designed with them in mind at all.

Industry teams use many techniques to prioritize and scope requirements:

• MoSCoW sorts requirements into Must have, Should have, Could have, and Won’t have.
• The Kano model categorizes features by the customer satisfaction they produce.
• The Value vs. Effort Matrix ranks features by the benefit they provide against the cost or effort required to build them.
• RICE scores and ranks features by multiplying Reach, Impact, and Confidence, then dividing by Effort.

We do not need to study those techniques here. The three categories in this section are a deliberately simple model: they state what is included, what is deferred, and what is excluded, so that we can reason about HopPress’s design.

The categories resulting from prioritization and scoping turn a long requirement list into a clear initial-release agreement. The agreement is provisional; it can change when new information leads us to revise our priorities, but a specific starting point makes proposed changes easier to discuss and evaluate.