Requirements
The term requirement, as used in PRINCE2, is practically a replacement for “scope”, “features” (mostly functional-features), or even “user stories”. Therefore, 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:
- 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.
- Dynamic scope in the details, with a less or more fixed high-level scope. 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 of PRINCE2.
Prioritizing
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:
- We may not have enough time to deliver everything, and it’s better to drop the least important ones when we run out of time.
- 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 and Manage by Exception principles, and also enables Agility.
The following is the levels of requirement specification:
- Very high-level: captured in the Project Product Description
- High-level: “product groups”, similar to what’s called “epic” or “theme” in the Agile context
- Intermediate level: Product Description
- Detailed: can be in the form of User Stories
See Also
Written by Nader K. Rad
This is (and will be) a work in progress: More details will be added in the future, depending on the feedback.
This wiki is developed and managed by an accredited trainer, independent of AXELOS. While aligned with their guidelines, it’s not an official resource.