Tailoring for agile delivery

Agile delivery and PRINCE2 are often presented as rivals. In practice they work at different levels and fit together well. Agile methods such as Scrum and Kanban describe how a team builds a product: in short iterations, with a prioritized backlog, frequent feedback and a working increment at the end of each cycle. PRINCE2 describes how a project is directed and managed: why it is justified, who decides, how much tolerance the team has and when the board needs to step in. A project can use agile methods for delivery and PRINCE2 for direction and management at the same time. The trick is to tailor PRINCE2 so that it changes the form and frequency of its controls without losing their purpose.

This lesson uses Ridgeline Water's outage alert app, a six-month, 420 thousand project to send customers push notifications about planned and emergency water outages, boil-water advisories and restoration times.

The project and its context

Ridgeline's billing team learned agile delivery during the smart metering project and now runs two-week sprints routinely. The app will be built by that team, extended to six people, with a small external supplier providing the notification service under a subscription contract. The executive is the director of customer service, Rosa Lindqvist. The senior user role is held by the manager of the utility's call centre, whose staff take the calls when outages are badly communicated. The senior supplier is the head of digital services. Ana Costa, who ran the billing interface work package in the metering project, is the project manager.

The context statement from lesson 2 points to the main tailoring decisions: agile delivery in two-week sprints, one supplier, moderate risk because outage messages carry public health advice, and personal data in scope. The rest of this lesson follows those decisions through the elements of PRINCE2.

Fitting agile roles into the project management team

Agile roles do not replace PRINCE2 roles; they sit inside them. A Scrum team's product owner, for example, decides what the team builds next and accepts completed work. In PRINCE2 terms that is part of the senior user's responsibility, so the product owner either holds the senior user role or works for the senior user, with delegated authority. The Scrum master helps the team work effectively, which overlaps with parts of the team manager role and with project support. The development team is the team in managing product delivery.

Two things stay the same. The board, and above all the executive, remains accountable for the project's justification and for deciding at stage boundaries whether to continue. And the project manager still manages the project day to day: coordinating with the supplier, operations and communications teams, tracking stage progress against tolerances and escalating when they are threatened. A Scrum master who also tried to be project manager, or a product owner who acted as executive, would blur roles that PRINCE2 keeps separate for good reasons.

Stages, releases and sprints

Management stages and agile timeboxes work at different levels. A stage is the unit of board commitment; a sprint is the unit of team work. Ana proposes three stages after a three-week initiation: stage 2 builds a minimum viable app with planned outage alerts (four sprints), stage 3 adds emergency and boil-water alerts with operations integration (four sprints), and stage 4 adds restoration estimates and accessibility improvements before handover (three sprints). Each stage ends with a release to customers, so the board's boundary decision is based on real usage data.

The stage plans are expressed as release plans: the goal of the release, the prioritized backlog for the stage, the budget, the tolerances, the dependencies on the supplier and operations, and the sprint calendar. That is still a plan in the PRINCE2 sense, with everything the board needs to authorize the stage. A bare sprint backlog would not be enough, because it has no tolerances, budget or dependencies.

Tolerances: fix time and cost, flex scope

Agile delivery usually fixes time and cost and lets scope vary. PRINCE2 supports this through tolerances. For each stage, Ana proposes zero tolerance on time (the release dates are fixed and publicized) and a small cost tolerance, and a scope tolerance defined by priority: all must-have features must be delivered, should-haves may be deferred to the next stage, and could-haves may be dropped. Quality tolerance is defined through the team's definition of done and the acceptance criteria for each alert type.

backlog = {"must": 34, "should": 21, "could": 13}     # story points in stage 2
velocity = [14, 17, 16]                                  # points per sprint so far
sprints_total, done = 4, sum(velocity)
remaining_sprints = sprints_total - len(velocity)
avg = sum(velocity) / len(velocity)
forecast = done + avg * remaining_sprints
must, should = backlog["must"], backlog["should"]
print(f"done after {len(velocity)} sprints: {done} points; forecast by stage end: {forecast:.0f}")
print(f"must-haves covered: {'yes' if forecast >= must else 'no'}")
print(f"should-haves covered: {max(0, min(should, forecast - must)):.0f} of {should} points")
print("scope tolerance:", "within" if forecast >= must else "forecast breach - escalate")

done after 3 sprints: 47 points; forecast by stage end: 63
must-haves covered: yes
should-haves covered: 21 of 21 points
scope tolerance: within

After three sprints the team has completed 47 points and is forecast to reach about 63 by the end of stage 2. All 34 must-have points are covered and 21 of the should-haves too, but only about 8 of the 13 could-have points will fit. Dropping or deferring could-haves is within tolerance and needs no escalation. If the forecast had fallen below 34 points, the must-haves would be at risk, the stage tolerance would be forecast to be exceeded and Ana would raise an exception, exactly as on a predictive project.

Products, quality and change

In agile delivery, products are often described as epics and user stories with acceptance criteria, and quality is built in through the definition of done, automated tests and sprint reviews. These can serve as PRINCE2 product descriptions and quality controls, provided they capture what PRINCE2 needs: the product's purpose, its quality criteria, who checks it and who approves it. The project product description, the description of what the whole project must deliver, remains a short separate product, because the board accepts the project against it at closure.

Change control is tailored too. Within a stage, adding, removing or reordering backlog items within the scope tolerance is normal agile work, and the product owner has delegated change authority for it. A change that would breach a tolerance, add cost or alter the project product description is an issue for the project manager and, if necessary, the board. The distinction keeps the team agile without letting scope drift silently.

Progress reporting and stage boundaries

The board receives a highlight report at the end of each sprint, as a one-page dashboard: sprint goal achieved or not, burn-up chart, forecast against tolerances, top risks and issues, and decisions needed. Sprint reviews give the project manager the information that checkpoint reports would normally provide. At each stage boundary the end stage report can be short, because the board has seen the detail sprint by sprint, but it is not dropped: it still consolidates the stage's results, reports on the business case and supports the decision to authorize the next stage.

Outage alerts carry public health information, so the quality criteria include the utility's obligations for drinking water advisories under provincial drinking water regulations and its agreements with the local medical officer of health. Accessibility criteria follow provincial accessibility standards and the WCAG level the municipality has adopted for public websites and apps.

Benefits in agile projects

One advantage of releasing at the end of each stage is that benefits can start before the project closes. The outage alert app's first release, with planned outage notices only, went live at the end of stage 2. Within six weeks, calls to the contact centre during planned shutdowns fell by about a third compared with the same streets the year before. Ana included the figure in the stage 3 end stage report, and Rosa used it in the updated business case. Early, measured benefits like this are powerful evidence at stage boundaries, and they make the board's decision to continue far easier to justify. The benefits management approach therefore schedules measurement after each release, not just after closure, and names the call centre manager as the person who gathers the data. The approach also records a caution: early users are not typical users, so the board treats first-release figures as encouraging rather than conclusive.