8.4 The Issues Practice in an Agile Context
Key Takeaways
- The issues practice addresses issues and controls changes to the project's baseline — it is what earlier editions called the Change theme.
- The issue management approach is tailored in an agile context by embracing and supporting change rather than resisting it.
- PRINCE2 recognises three issue types: a request for change, an off-specification, and a problem or concern.
- Most change in an agile project is absorbed at delivery level by re-prioritizing the backlog inside a fixed timebox, without formal change control, and informal issues are recorded in the daily log.
- Formal change control is reserved for changes to the baseline itself — the agreed products, tolerances or business case.
8.4 The Issues Practice in an Agile Context
Quick summary: The issues practice addresses issues and controls changes to the project's baseline. It is the Version 7 successor to the Change theme. Its agile tailoring is to embrace and support change — absorbing most of it by re-prioritizing the backlog within a fixed timebox, and reserving formal change control for changes to the baseline itself.
Purpose, and the name change
The purpose of the issues practice is to identify, assess and control any unplanned events, and to control changes to the project's baseline.
If your notes list a Change theme rather than an Issues practice, they are pre-Version-7. The rename widened the scope: the practice was always about more than change requests, and issues names the whole of it.
Issue versus risk
The distinction is fundamental and frequently examined.
| Risk | Issue | |
|---|---|---|
| Timing | Has not happened — a possible future event | Has happened, or has been requested now |
| Nature | Uncertain, may be a threat or an opportunity | Certain — it is real |
| Recorded in | Risk register | Issue register (or daily log, if informal) |
| Response | Avoid, reduce, transfer, share, accept, exploit, enhance | Assess impact, then decide and act |
When a risk materialises, it becomes an issue. That sentence answers a large share of questions on this topic.
The three issue types
| Type | What it is | Example |
|---|---|---|
| Request for change | A proposal to change something already baselined | The senior user asks for a different approval workflow |
| Off-specification | Something that should have been provided but is not, or does not meet its specification | A supplier's component fails its performance criterion |
| Problem or concern | Anything else the project manager needs to resolve or escalate | A key specialist is reassigned at short notice |
Tailoring: embracing and supporting change
The examinable tailoring statement is that the issue management approach in an agile context is tailored by embracing and supporting change.
This follows directly from the Agile Manifesto's responding to change over following a plan. In a plan-driven project, change is an exception to be controlled, and every change consumes management effort in raising, assessing and approving. In an agile project, change is expected — requirements are discovered — so a change-control process that treats every adjustment as an exception would consume the whole project.
Be careful with the distractors here. Emphasizing the frequency of releases tailors the benefits management approach; defining the MVP is a business case technique; defining the form of procurement belongs to commercial arrangements.
Where change is absorbed, and where it is controlled
The resolution is a two-tier model, and understanding the boundary is the core of this section.
Tier 1 — absorbed at delivery level, no formal change control
Change inside the agreed baseline is handled by re-prioritizing the backlog:
- The product owner re-orders the backlog as understanding improves.
- New work enters an in-flight timebox only by trading or swapping — equivalent work leaves, with the product owner agreeing priorities.
- Detail within an item is refined continuously; refinement is not change control.
- Low-priority Should-have and Could-have items drop out when a timebox is under pressure.
None of this requires a change request, because none of it alters what was baselined: the timebox still ends on its date, at its cost, meeting the Definition of Done, delivering the agreed Must-have outcomes.
This is what "embracing change" means operationally. Fixing time and cost while flexing scope is precisely what creates the room to absorb change without bureaucracy.
Tier 2 — formal change control
Formal change control applies when the baseline itself must change:
- A Must-have requirement is added or removed
- The release date, the budget or a tolerance must change
- The business case is materially affected
- The Definition of Done or a quality criterion must change
- A contractual or regulatory commitment is affected
Here the change is raised as a request for change, assessed for impact on time, cost, quality, scope, benefit, sustainability and risk, and decided by the appropriate authority — the project manager within tolerance, the change authority if one has been delegated, or the project board.
Artifacts
- Issue management approach — how issues and changes will be handled, including the change authority's delegated limits and any change budget.
- Issue register — the formal record of issues raised, assessed and resolved.
- Issue report — the detailed record of a single significant issue.
- Daily log — where informal issues and the actions required are recorded. This is the lightweight route: not everything needs a register entry, and the daily log is what keeps the formal machinery proportionate.
- Change budget — money set aside in advance for approved changes, so that change does not automatically become an exception.
The change budget deserves emphasis on an agile project. Setting one at initiation acknowledges in advance that change will happen and gives the project manager room to approve it within delegated limits — turning what would otherwise be a stream of escalations into ordinary management.
How should the issue management approach be tailored in the issues practice for an agile project?
A product owner re-orders the backlog mid-stage so that a Could-have item is dropped and a newly understood Should-have item takes its place, at equivalent size. What does this require?
Where are informal issues and the actions required recorded?