12.3 PRINCE2 Agile guidance for the Plans theme
PRINCE2 supports any type of planning style from a conventional Gantt chart to a simple backlog list. Both styles are in keeping with the product description for a plan (see Appendix A.16). It may be the case that more than one planning style is used on a single project. There may be a tendency to use more conventional planning techniques for the higher levels of planning (e.g. where departmental and organizational dependencies may exist) but this may not be necessary. When using PRINCE2 in an agile environment a Gantt chart can be of limited value as it is not geared to monitor and control the amount of products delivered or their quality.
12.3.1 Collaborative planning
Agile planning is collaborative, for all types of plan and at all levels, and this is desirable in order to create an environment where the people involved in a project can respond to changing circumstances. If a group of people are working to a plan that was created by someone else (e.g. the project manager) there is likely to be less commitment and responsiveness.
This does not mean that the role of the project manager or team manager is any less important, but it does mean that they need to facilitate this style of planning.
12.3.2 Using empiricism to plan
Empiricism has many advantages, and to use PRINCE2 in an agile environment this needs to be fully understood and embraced as far as is practicable. A potential drawback with some of the agile planning techniques is that in a project context (where a project is finite), we need to estimate and plan before we start and not after.
PRINCE2 needs a project plan with an end date for the following reasons:
- It will enable the project to be justified and therefore authorized.
- It will provide a baseline against which progress can be measured and stages defined.
- Projects are finite pieces of work that are ‘bounded’; therefore without an end date PRINCE2 and PRINCE2 Agile would not see the work as a project.
- From a supplier perspective it enables them to give the customer a price and a delivery date.
- It will show if a minimum viable product (MVP) can be created in time.
Stage plans and team plans are similarly affected, albeit at a lower level.
12.3.3 Planning horizons
Having an end date is one thing, but how accurate and realistic it is can be something quite different.
Both agile and PRINCE2 accept the premise that the further you look into the future the more uncertainty there is. This means that longer-term estimation will need an increasing margin of error compared with shorter-term estimation. This leads to the use of the term ‘planning horizon’ whereby a plan for the next two weeks would be quite detailed and have a relatively low margin of error, whereas a plan for the next 12 months would be much less detailed and have a relatively high margin of error (see Figure 12.3).
Long-term planning addresses the uncertainties and unknowns (sometimes referred to as the ‘cone of uncertainty’) by providing a level of confidence or a range with each estimate in the form of agreed tolerances (see section 25.4).
Estimation and planning are seen as evolutionary when using agile and not a one-off activity. They are carried out throughout the project and for every level of plan (see Table 12.1).
|PRINCE2 plan level||Possible agile equivalent||Typical estimation approaches and/or techniques|
(Corporate or programme)
By analogy with other projects or by using more predictive or ‘rational’ means or expert knowledge
Release (one or more)
Effort per feature in the form of points and expected value or by using existing lead times if available
Sprint (one or more)
Effort per backlog item in the form of points or by using existing lead times if available
Table 12.1 Estimation approaches that may be used at each PRINCE2 plan level
Empirical and emergent planning is more likely to occur in the lower levels of plan such as with product delivery within the Managing Product Delivery process (i.e. where agile is predominantly used) because the timescales (and therefore the planning horizons) will be short, perhaps in the order of 2–4 weeks. The tasks at this level of plan will be so small (e.g. a matter of days or hours) that feedback in the form of metrics will be frequent and planning will have a relatively low margin of error. ‘Just-in-time’ (or JIT) planning at these low levels of plan is sometimes referred to as ‘rolling-wave planning’ or ‘progressive elaboration’.
A concept in agile that refers to creating solutions and making decisions in a way that gradually converges on an accurate solution and does not involve a lot of upfront work. The opposite would be to spend time and try to predict how things will happen. An example would be ‘emergent architecture’ whereby a lot of work could be done in advance to decide how the product will be built, or work could be started on the product and then the best architecture would emerge as the product develops.
A more predictive style of the planning would typically be applied for higher-level plans (e.g. project plans and possibly stage plans) as these have a relatively higher margin of error. However, empiricism can still be used at these levels, and it would be a good sign of an organization’s maturity if measures and metrics from previous projects and stages were used to estimate without a lot of ceremony.
Either way, over-planning should be avoided as it is not possible to cover and plan for every eventuality. Therefore the attitude should be to do ‘enough’ planning and no more, otherwise the extra work will outweigh the potential benefits following the law of diminishing returns. The Agile Manifesto puts emphasis on responding to change rather than following a plan.
12.3.4 Align product-based planning to features
One of the most powerful techniques in PRINCE2 is that of product-based planning, and this can be applied very easily in agile situations. When creating a product breakdown structure or product description the focus will typically be similar to the content of a requirement or user story. It would not be appropriate to use technical phases during this exercise in an agile context (e.g. analysis, design, build and test) as this is not the focus of the agile way of working.
When using PRINCE2 in an agile context it is important to plan around features and groups of features. Due to the primary focus of agile being based on flexing what is being delivered (see Chapter 6), features expressed in the form of requirements or user stories represent the contingency on a project when combining PRINCE2 with agile. Conversely, time and cost are not used as contingency and are therefore likely to remain stable.
Clearly illustrating what constitutes the MVP is recommended.
Product-based planning can be used for any level of plan in PRINCE2. Perhaps at the lowest level a team may prefer to use its own form of activity planning but the option to use product-based planning should at least be considered.
12.3.5 A possible limitation with sprint planning by priority only
When working at the delivery level with agile, planning centres around the immediate future and this often relates to a timebox of 2–4 weeks. Although flow-based approaches do not typically use a timebox, both flow-based and iterative timeboxing approaches focus predominantly upon prioritization. That is to say the focus is on doing the highest-priority work as soon as possible.
This is typified by sprint planning in Scrum (see Appendix H) whereby the highest-priority items in the product backlog are broken down into tasks by the team that will be developing them. An indication of a well-maintained product backlog is that each entry in the product backlog is independent of any other entry, thus increasing the likelihood that work can be carried out by any member of the team with the appropriate skills, without impacting on any of the others. However, there will typically be limitations due to people having certain types of skill and experience, and which people are available; therefore a balance will always need to be struck.
Projects by their very nature are challenging, and therefore when planning at the levels above the product delivery level it is usually too simplistic to create a prioritized to-do list and start working from the top. Longer-term planning needs to consider many factors such as dependencies (internal and external to the project) and the grouping together of similar work items.