3.2 MVP, Burn Charts, Workshops and Agile Events

3.2 MVP, Burn Charts, Workshops and Agile Events

Quick summary: A minimum viable product is the smallest version that generates the feedback you need. Burn charts visualize progress — down towards zero remaining, or up towards a total that may move. Workshops are PRINCE2 Agile's primary collaborative format and are attached by name to each process. Planning, review and retrospective events give an iteration its rhythm.

Minimum viable product

A minimum viable product (MVP) is a version of the product with just enough features to generate the feedback the team needs in order to learn something decisive about the product idea.

The words earn their place individually:

• Minimum — the smallest thing that will do the job. Anything more is waste until the assumption is tested.
• Viable — it must actually work well enough for real users to use it. A broken prototype produces no valid learning.
• Product — it is a product, not a slide deck. Real behaviour is the evidence sought.

Two traps to avoid, both of which appear as plausible exam distractors:

1. An MVP is not a finished product ready for full-scale launch. If it were, there would be nothing left to learn.
2. An MVP is not merely "an early release". The definition is about generating the feedback needed to learn, not simply about shipping sooner. An early release with no measurement attached is not an MVP; it is just an early release.

The MVP is the delivery vehicle of Lean Startup's build-measure-learn loop, and in a PRINCE2 Agile project it connects directly to the business case practice: an MVP is how you buy evidence that the forecast benefits are real, before committing the remaining budget.

Burn charts

Burn charts are the standard visual progress instrument, and they belong to the progress practice.

Burn-down chart

Plots work remaining on the vertical axis against time on the horizontal, falling towards zero. Remaining work may be in story points, hours or item counts.

• Easy to read at a glance: is the line heading for zero by the deadline?
• Its weakness is that it hides scope change. If the team completes ten points and eight points of new work are added, the line barely moves — and nobody can tell whether the team is slow or the scope grew.

Burn-up chart

Plots work completed rising, against a second line showing total scope.

• Because scope is drawn as its own line, scope change is visible. A rising total line explains a flat-looking completion trend immediately.
• This makes burn-up charts the better instrument in a PRINCE2 Agile project, precisely because scope is the variable that flexes. Governance needs to see the flexing, not have it disguised.

Both are typically displayed on a team dashboard or project dashboard, so that anyone can read current status without asking for a report.

Workshops

A workshop is a facilitated, time-bound, collaborative working session with a defined output. It is not a meeting to share information; it is a session in which a group produces something together.

Workshops are central to PRINCE2 Agile because they resolve the common-language problem directly: getting the project board, the project manager, the product owner and the delivery team into one room to produce a shared artifact does more for alignment than any amount of document circulation.

What makes a workshop work:

• A named output. A prioritized user-group list, a release map, a set of team norms — something concrete exists at the end.
• The right people. Everyone whose agreement is needed, and nobody whose presence suppresses candour.
• A facilitator. Someone accountable for the process, not the content.
• A timebox. The session ends when it ends; the output is right-sized to the time available.

Version 2 attaches named agile workshops to each of the seven processes — the agile enablement workshop, the project canvas workshop, the kickoff workshop, release planning, team planning, progress review, team retrospective, project retrospective and project closure workshops. Chapter 10 maps each one to its process; expect several marks on this mapping.

Planning, review and retrospective

Three recurring events give an iteration its rhythm. Every mainstream agile approach has some version of them.

Planning

Held at the start of a timebox. The team and product owner agree what will be attempted: the highest-priority ready items are pulled in, sized against the team's capacity, and the goal for the timebox is stated. Output: a committed set of work and a shared understanding of it.

Review

Held at the end of a timebox, focused on the product. The team demonstrates the increment to the product owner and stakeholders, who inspect it and give feedback. The backlog is updated in the light of what is learned. Output: feedback and a re-prioritized backlog.

Retrospective

Also held at the end, but focused on the process and the people rather than the product. The team inspects how it worked — what helped, what hindered — and agrees a small number of improvements to try next timebox. Output: agreed improvement actions the team itself owns.

The review/retrospective distinction is examinable. Review inspects what was built; retrospective inspects how the team built it. A team that runs reviews but skips retrospectives improves its product and never improves itself, which is why the continual-improvement characteristic of the agile mindset depends on the retrospective specifically.

PRINCE2 Agile scales the retrospective idea: the team retrospective workshop happens at team level within delivery, and the project retrospective captures lessons at project level, feeding the "learn from experience" principle and the lessons that inform later stages and later projects.