25.4 Requirements decomposition and granularity
Essential to the success of using PRINCE2 with agile is to ensure that requirements are defined at the appropriate level of understanding during each stage of a project. This normally involves a simple three-step process (see Table 25.2 and Figure 25.1), although this may be done in two steps on smaller projects where the processes of Starting up a Project and Initiating a Project may have been combined.
This could be likened to JIT (just-in-time) inventory management in that just enough detail needs to be available at the right time. The ‘Level of requirement’ column in Table 25.2 is only a very general guide and is included to give at least some idea of scale, but this should not be seen as anything more than a rudimentary rule of thumb. If a team is prioritizing 200 user stories it should not be in the pre-project stage!
The ‘Metaphor’ column is intended to provide help with visualizing the need to take requirements and break them down through the duration of the project. Too much detail early on can obscure the bigger picture.
|Project stage||Level of requirement and a possible guide as to how many||Metaphor||Possible format|
High level (possibly less than 10)
Key objectives of the project in bullet point form – perhaps listed under the project product description as ‘composition’ or defined as product groupings
Intermediate level (possibly more than 10 but less than 100)
Product descriptions, epics
Detail level (possibly more than 100)
Detailed requirements/user stories relating to the product descriptions defined in the initiation stage
Table 25.2 Typical levels of requirements decomposition
From an estimation point of view (in the form of time, cost or benefits), the margin of error at each of these stages could be as follows:
- pre-project, 50–100 per cent
- initiating stage, 20–40 per cent
- delivery stage(s), 10–20 per cent.
Again, this should only be seen as a guide and for illustrative purposes as this will vary according to such things as industry sector, organization and experience. It is sometimes referred to as the ‘cone of uncertainty’. The real margin of error will vary from project to project depending on each project’s conditions and level of uncertainty.