PRINCE2 Agile 2016
Previous Section   Next Section

21.3 PRINCE2 Agile guidance on Managing a Stage Boundary

It is important to use stage boundaries or ‘fire-breaks’ appropriately when working in an agile way as although the delivery teams may be very content, working to a regular cadence and being very productive, because their focus is on product delivery they may not be aware of the wider context of their work. Their work may be going very well but they may not be aware that a competitor has launched a rival product and the expected benefits of the project are now significantly lower. Despite the good efforts of the delivery teams it may be prudent to cancel the project as it is no longer viable.

Tailoring guidance that may be appropriate is as follows:

  • Reviewing how much is being delivered (and the quality of it) compared with what had been planned. This would include comparing the amount of value being delivered with the amount of cost incurred to create that value in order to ascertain if the project is still on track and is still viable.
  • What has been released would typically be reviewed. What benefits are being realized?
  • The appropriate use of agile could be reviewed in case risks are surfacing in certain areas (e.g. if the level of customer involvement is lower than expected more formality may be required).
  • Release planning would typically be reviewed. For example, would it be a good idea to increase the frequency of the releases (if it is possible)? Would it be a good idea to alter the number of sprints (or their lengths) inside each release?
  • The efficiency of configuration management and the choice of configuration item records could be assessed with respect to the iterative and incremental nature of the agile way of working. For example, are the configuration item records defined at too low a level and is this causing an unnecessary overhead?
  • Is it worth carrying out a formal workshop to review the stage (perhaps as part of a release review) and then plan the next stage (see Chapter 22, Closing a Project, for how to handle a similar one) or at least a large-scale demo for as many stakeholders as appropriate? (NB: it is unlikely that this event will take place at the very end of a stage – e.g. on the final day.)
  • Decide on which of the suggested improvements to the way the teams are working (perhaps created during a release retrospective) can be reasonably expected to be adopted in the next release. Further learnings could be formalized at this point and given to project support so these lessons can help the wider organization.

Table 21.1 shows PRINCE2 activities for Managing a Stage Boundary and how they relate to agile artefacts and events (all product description references for PRINCE2 products are located in Appendix A).

PRINCE2 activities and products Applicable agile artefacts and events
  • Plan the next stage:
    • Update the project initiation documentation (PID), A.20
    • Create the stage plan, A.16
    • Create/update configuration item records, A.5
    • Update risk register, A.25
    • Update issue register, A.12
    • Update quality register, A.23
  • Artefacts:
    • Product backlog (done/not done)
    • Release backlog (done/not done)
    • Potentially shippable increment
  • Event(s):
    • Release planning
    • Release reviews
    • Release retrospectives

Note: Sprint planning would typically be too detailed at this point but it may be useful.

  • Update the project plan:
    • Update the project plan, A.16
    • Update the issue register, A.12
    • Update the risk register, A.25
  • Artefacts:
    • Product backlog (done/not done)
    • Release backlog (done/not done)
    • Information radiators
  • Event(s):
    • Release review
    • Release planning
  • Update the business case:
    • Update the business case, A.2
    • Update the benefits review plan, A.1
    • Update the risk register, A.25
    • Update the issue register, A.12
  • Artefacts:
    • Product backlog (value enabled)
    • Release backlog (value enabled)
    • Information radiators
  • Event(s):
    • Release review
    • Release planning
  • Report stage end:
    • Create end stage report, A.9
    • Create lessons report, A.15
    • Create follow-on action recommendations
  • Artefacts:
    • Product backlog (done/not done, value enabled)
    • Release backlog (done/not done, value enabled)
    • Information radiators
  • Event(s):
    • Release planning
    • Release review
    • Release retrospectives
  • Produce an exception plan:
    • Update the PID, A.20
    • Create exception plan, A.16
    • Create/update configuration item records, A.5
    • Update risk register, A.25
    • Update issue register, A.12
    • Update the quality register, A.23
  • Artefacts:
    • Product backlog (done/not done)
    • Release backlog (done/not done)
    • Impediments from daily stand-ups
    • Outputs or decisions from a retrospective or a review
  • Event(s):
    • Sprint planning
    • Release planning

Table 21.1 PRINCE2 Agile activities for Managing a Stage Boundary

21.3.1 How to ...

There are many behaviours, concepts, frameworks and techniques that are used in agile and referenced throughout this manual. Table 21.2 provides cross-references to some of the most relevant for use during Managing a Stage Boundary.

Chapter and section references

Determine value

Section 9.4.1

Plan stages and releases

Chapters 12, 27

Assess and improve team performance

Section 19.4.1

Track progress when using agile

Chapter 15

Define quality criteria and acceptance criteria

Chapter 25

Manage risks and issues

Chapters 13, 14

Assess the risks associated with agile

Chapter 24

Break down requirements and products in a way best suited to agile

Section 25.4

Run workshops

Section 26.4.1

Tailor any of the PRINCE2 management products

Chapter 23

Table 21.2 Relevant agile guidance for Managing a Stage Boundary

Previous Section   Next Section

Collapse