PRINCE2 Agile 2016
Previous Section   Next Section

19.3 PRINCE2 Agile guidance on Controlling a Stage

19.3.1 The structure of a stage

  • Stages are likely to be made up of timeboxes (e.g. one or more releases, containing one or more sprints), with the focus being on delivering sets of features ideally into operational use and therefore enabling their respective benefits.

19.3.2 Work assignment

  • Planning, scheduling and estimating are likely to be carried out as a collaborative team-based exercise.
  • At the delivery level team members typically select the next piece of work to be done based on the order decided by the customer subject matter expert (SME) who is in the delivery team (such as a product owner). As a result, work is typically not assigned to specific team members.
  • Work packages provide the flexibility (e.g. through tolerances) needed to enable teams to self-organize, and their sign-off may be informal. Reviews and demos at the end of a sprint or a release provide rich and regular feedback to the customer as a means to validate that the acceptance criteria for the agreed work package have been met.
  • A work package may contain several timeboxes (e.g. in the form of sprints) and although each one will deliver something, they may not necessarily deliver something into operational use.

19.3.3 Monitoring progress and reporting

  • Within agile environments, teams report progress to one another during the daily stand-up. The project manager or team managers may be invited to attend/assist stand-up meetings if appropriate, and/or facilitate stand-up meetings.
  • Reporting of progress during a sprint within a release to which it belongs is typically done via information radiators.
  • Reporting of progress at the end of a sprint or a release is done via the sprint or release review and the optional product demo, which provides the opportunity to discuss planned features which were not delivered or those that were but were not originally planned for the release.
  • Monitoring and forecasting in general is more likely to be in an empirical style (based on evidence).
  • Progress is more likely to be shown as a burn chart rather than a Gantt chart.
  • Although PRINCE2 identifies six aspects of control the project manager will focus on flexing the scope and the quality criteria of the defined products. The details of these products may be held in the form of backlogs for the project as a whole, the stage, a release inside a stage or a sprint.

19.3.4 Risks and issues

  • The daily stand-up provides the delivery team with the opportunity to identify issues. Issues may be referred to as blockers, impediments or smells by the delivery team. This approach ensures that issues are uncovered and escalated quickly to ensure that sprint and release goals are not compromised.
  • Sprint and release retrospectives also provide an opportunity for risks and/or issues that may have been missed in the daily stand-ups or review sessions to be highlighted by the team.
  • Risks and issues identified by the agile assessment need to be monitored regularly.
  • During retrospective sessions teams are encouraged to select only those corrective actions that they can reasonably expect to be able to implement in the next sprint or release. This makes it more likely for the corrective action to be successful and to have the greatest positive effect for the team.

Table 19.1 shows PRINCE2 activities for Controlling a Stage 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
  • Authorize a work package:
    • Create a work package, A.26
    • Create/update the configuration item record(s), A.5
    • Update the quality register, A.23
    • Update the risk register, A.25
    • Update the issue register, A.12
    • Review team plan, A.16
    • Update the stage plan, A.16
  • Artefacts:
    • Product backlog
    • Release backlog
    • Sprint backlog
  • Event(s):
    • Release planning
    • Sprint planning
  • Review work package status:

    (NB: A work package can contain one or more releases and one or more sprints)

    • Review checkpoint report, A.3
    • Review team plan, A.16
    • Update stage plan, A.16
    • Update configuration item record(s), A.5
    • Update the risk register, A.25
    • Update the issue register, A.12
  • Artefacts:
    • Burn charts
    • Sprint backlog (done/not done)
    • Information radiators
  • Event(s):
    • Daily stand-ups
    • Sprint reviews
    • Release reviews
  • Receive completed work packages:
    • Confirm configuration item record(s), A.5
    • Update stage plan, A.16
  • Artefacts:
    • Potentially shippable product
    • User story acceptance criteria
  • Event(s):
    • User acceptance (during a sprint demo or release demo)
    • Sprint review
    • Sprint demo
    • Release review
    • Release demo
  • Review the stage status:
    • Update the risk register, A.25
    • Update the issue register, A.12
    • Update the stage plan, A.16
    • Update the lessons log, A.14
    • Create/update the issue report, A.13
  • Artefacts:
    • Burn charts
    • Sprint backlog (done/not done)
    • Information radiators
  • Event(s):
    • Daily stand-ups
    • Sprint reviews
    • Release reviews
  • Report highlights:
    • Create highlight report, A.11
  • Artefacts:
    • Burn charts
    • Information radiators
  • Event(s):
    • Sprint demos
    • Sprint reviews
    • Release demos
    • Release reviews
  • Capture and examine issues and risks:
    • Update the daily log, A.7
    • Create issue report, A.13
    • Update issue register, A.12
    • Update risk register, A.25
  • Artefacts:
    • Impediments from Daily stand-ups
    • Information radiators
  • Event(s):
    • Daily stand-ups
    • Sprint planning
    • Sprint reviews
    • Sprint retrospectives
    • Release planning
    • Release reviews
    • Release retrospectives
  • Escalate issues and risks:
    • Create exception report, A.10
    • Update issue register, A.12
    • Update risk register, A.25
    • Update issue report, A.13
  • Artefacts:
    • Impediments from daily stand-ups
    • Outputs or decisions from a retrospective, sprint review or release review
  • Take corrective action:
    • Update issue register, A.12
    • Update risk register, A.25
    • Update issue report, A.13
    • Update stage plan, A.16
    • Update configuration item records, A.5
    • Update daily log, A.7
  • Artefacts:
    • Daily impediments
    • Sprint backlog
    • Release backlog

Table 19.1 PRINCE2 Agile activities for Controlling a Stage

19.3.5 How to ...

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

Chapter and section references

Plan stages, release and sprints

Chapters 12, 27, Appendix H

Understand the benefits of transparency, collaboration and self-organization

Section 7.4

Estimate

Section 12.4.1

Create a work package

Section 20.3.1

Use tolerances

Chapter 6

Carry out stand-ups, Scrum meetings and sprint reviews

Appendix H

Use information radiators

Section 15.4.2

Use burn charts

Section 15.4.1

Carry out retrospectives

Section 19.4.1

Tailor any of the PRINCE2 management products

Chapter 23

Table 19.2 Relevant agile guidance for Controlling a Stage

Previous Section   Next Section

Expand