From PRINCE2 Agile wiki
Jump to: navigation, search

The term requirement, as used in PRINCE2, is practically a replacement for "scope", "features" (mostly functional-features), or even "user stories".

The requirements focus area explains the way scope is managed in PRINCE2 Agile.

Scope Management in Agile

Agile methods have two major approaches in different contexts:

  1. Dynamic scope, both at high-level and details; the scope just emerges during the project by focusing on the business value, vision, and feedback loops.
  2. Dynamic scope in the details, with a less or more fixed high-level. In this case, the final product is defined in high-level and we only adapt in how to realize those high-level definitions by small features.

The second approach is the default in PRINCE2 Agile, and the first one might not be compatible with the governance layers brought by PRINCE2.


Regardless of the approach, at least a level of scope is dynamic in Agile, which means that its elements can be added, removed, or reinterpreted easily. In order to do so, some kind of prioritization is required. The development would be focused on the highest priority items first, because:

  1. We may not have enough time to deliver everything, and it's better to drop the least important ones
  2. More important items generate more useful feedback, which in turn, helps with adaptation

The ideal way of prioritization is to assign business values to each item and use it for ordering (prioritizing). Since this is difficult in most situations, a simple MoSCoW Prioritization is more common and practical.

Note: MoSCoW Prioritization can also be used for quality criteria.

Levels of Requirement Specification

Like planning in general, requirement specification should be done in multiple levels, from high-level to detail. This is aligned with the Manage by Stages Principle and Manage by Exception Principle, and also enables Agility.

The following is the levels of requirement specification:

Process Model

PRINCE2 Agile Process Model state35.png



  • The above image assumes that Scrum is used in the delivery level, which is not necessary.
  • The number of stages, releases, and Sprints are just examples, as well as the exception in the third stage.
  • The diagram is schematic and many details are not shown.

See Also