Review & Prioritise

The Review stage takes nominated features and prepares them for full specification. Each feature needs a priority, categorisation metadata, and an approval decision before it can move to the Create stage.

The review flow

Features arrive in Review after being nominated in the Plan stage. The flow is:

Nominated - the feature appears in the Review stage, ready for assessment
Prioritised - MoSCoW priority is assigned
Categorised - metadata is set (feature category, service type, service name)
Decision - the feature is approved, rejected, or held

MoSCoW prioritisation

Every feature gets a priority that tells the team how to make trade-offs:

Must Have - the product is unacceptable without this feature. If you can't ship without it, it's a Must Have.

Should Have - important and expected, but the product can function without it for now. Should Haves are the first candidates for a subsequent release.

Could Have - desirable but not necessary. These are the first features dropped when time or resources get tight.

Won't Have - explicitly out of scope for this release. Marking something as Won't Have is just as valuable as marking it Must Have - it prevents scope creep by making the boundary visible.

The 60% rule

Must Haves should be 60% or less of your total features. If everything is a Must Have, the prioritisation is meaningless - you can't make trade-off decisions when there's nothing to trade off.

The test: "Would you accept delivery without this feature?" If the answer is no, it's a Must Have. If the answer is "I'd rather have it, but yes" - that's a Should Have.

Categorisation

Categorisation adds metadata that describes the technical characteristics of the feature. This information is used later for organising features into feature sets and for tracing features to logical components.

Feature Category - the type of behaviour. Common categories:

Feature Dialogue - user or protocol interactions
Event Processing - handling scheduled or triggered events
State Handler - managing system states and transitions
Device Configuration - hardware setup
Hardware-Software Interface - the boundary between firmware and hardware

Service Type - the implementation pattern the feature follows. Examples: Feature Service, Event Scheduled VSM, Hardware Timing, Component Utility.

Service Name - the logical component this feature belongs to. This often takes the name of the feature set the feature will be assigned to in the Create stage.

Approval decisions

Once a feature has priority and categorisation, the reviewer makes a decision:

Approve - the feature is necessary, correctly described, and ready for full specification. Approved features get a permanent F-number and move to the Create stage. Approved features are locked - only authorised users can make changes.

Reject - the feature is not needed for this project. Rejected features are archived but not deleted.

Hold - the feature might be needed but the team isn't ready to decide. Held features stay in Review and can be revisited later.

Reviewing in bulk

When you have many nominated features, you can work through them in sequence from the Review list. Open each feature, set the priority and categorisation, and make the approval decision.

For efficiency, categorise features with similar characteristics together - all the feature dialogues at once, all the hardware-software interfaces at once. This helps maintain consistency in how metadata is applied.

Assigning reviewers

Features can be assigned to specific reviewers. The assigned reviewer is responsible for assessing the feature's priority, categorisation, and readiness for approval. This is particularly useful on larger teams where different people have expertise in different system areas.

In the Reference Project, switch to the Review tab to see how approved features show their MoSCoW priority and categorisation metadata.

Capture Features - the preceding stage
Define Specifications - the next stage after approval
The Four Stages - why Review comes between Plan and Create