The monthly transformation steering committee receives the same forty-slide pack as everyone else on the distribution list. The sponsor turns to slide three, reads the traffic lights and closes the file. Two workstream leads bring their own spreadsheets, because the pack shows their work at a level they cannot act on. Finance arrives with a separate benefits tracker whose numbers do not match slide twenty-two.
Transformation reporting works when every view is built from a user story — who needs to see what, in order to decide or do what — and delivered in small, bundled rounds rather than designed once for everyone. The technique comes from agile delivery and transfers almost unchanged. Only the product differs: not an application, but the information layer a transformation runs on.
One reporting pack serves the person who designed it
A single pack is the cheapest thing to build: one template, one data pull, one distribution list. It also spares the PMO six awkward conversations about what each audience actually needs.
The cost arrives later and lands elsewhere. Every audience the pack fails builds its own substitute: a workstream tracker, a finance reconciliation, a line manager’s private list of who has been trained. Within a quarter the transformation runs on four versions of the truth, and the steering committee spends its first twenty minutes reconciling them.
The usual response is a request for better reporting. A sharper layout does not help, though, if nobody has asked who the report is for. As I argued in Better Reporting Will Not Fix a Governance Gap, reporting is a downstream output of governance: decisions define information needs, and information needs define reports. User stories are the practical method for walking that chain, one audience at a time.
Personas are defined by the decisions they make, not by their titles
In agile delivery, a persona is a type of user with recognisable goals. In transformation reporting, three things define a persona: the decision it makes, the rhythm in which it makes it, and the time it has to read anything.
Most transformations have five or six. The sponsor and steering committee decide on scope, funding and escalations, usually monthly. The programme manager rebalances resources and dependencies every week. Workstream leads manage their own plans day to day. Line managers release people and drive adoption. Finance tracks cost and benefits against the business case. Above them sits a board that sees the transformation a few times a year, among many other agenda items.
Two people with the same title can be different personas. A sponsor who chairs a weekly forum needs something different from one who sees the programme only at quarterly gates. The reverse holds too: a workstream lead in operations and one in IT may share a persona, because they make the same kind of decision. If the decisions match, the view can match.
A reporting user story names a decision, or it names nothing
Agile teams write stories in a simple form: as a persona, I want a capability, so that I get a benefit. For reporting, each part needs sharpening:
- Who: the persona, defined by decision and cadence — “steering committee member, monthly scope and funding decisions”, not “management”.
- What: a verb that describes use — see the three workstreams slipping most against baseline, compare the benefits forecast with the business case, be alerted when a key milestone moves by more than a month.
- So that: the decision or action the view enables — so that I can decide which workstream receives the contingency.
- Acceptance criteria: the data source and its owner, the refresh frequency, any alert threshold, and the medium the view lives in.
The “so that” clause is the test. If nobody can complete it with a decision or an action, the view is curiosity, not reporting, and it goes to the bottom of the backlog. This one rule removes a good part of most reporting packs: the slides that exist because they always have.
The acceptance criteria do a second job. A story whose data has no owner, or which needs a refresh the source cannot deliver, is not ready. Writing that down early turns a vague complaint about “bad data” into a named gap that someone can close.
The medium is an acceptance criterion, not the starting point
Many reporting initiatives start with the tool: “we are moving to Power BI”. The tool then decides what everyone sees. Stories reverse the order.
A board needs a frozen, agreed snapshot it can annotate and minute — a slide pack, versioned and signed off before the meeting. A workstream lead needs to sort, filter and recalculate, which means a spreadsheet or an export that behaves like one. A programme manager chasing a slipping dependency needs to drill from the portfolio down to a single task, and that is where an interactive dashboard earns its licence cost.
The same data can feed all three. What must not happen is one medium imposed on every persona because it suited whoever chose it. It is the reporting version of a mistake I described in Design the Portfolio Process Before You Choose the PPM Tool. Write the medium into each story’s acceptance criteria, and the tool question becomes an answer rather than an argument.
Bundle stories into improvement rounds, and ship something usable in each
A first round of persona interviews typically produces thirty or forty stories. Building them all at once recreates the big-bang reporting project the method was meant to avoid. Treat them instead as a backlog, and release them in rounds.
Prioritise on two axes: the value of the decision a story supports, and the readiness of its data. High-value stories with ready data go first. High-value stories with weak data become data-quality actions with an owner and a date. Low-value stories wait, and many quietly die there, which is the right outcome.
Bundle each round around something its stories share: one data source, one forum or one persona. Shared data means one extraction and one validation. A shared forum means one review can accept the whole round. Mixing unrelated stories into one round is how reporting teams end up half-finishing everything.
Run the rounds on the governance cadence, typically four to six weeks, so each one lands in front of the forum that uses it. Round zero is always the minimum the steering committee needs to steer: decisions due, escalations open, the few milestones that matter. Every later round ends with a short review with its personas. Was the view used? Did it support the decision? What is still missing? Count use, not views delivered.
Transformations change phase, and their stories expire
A transformation in design asks different questions from one in deployment, adoption or benefits tracking. In design, the steering committee watches scope decisions and readiness. In deployment, it watches milestones and dependencies. During adoption, the most important persona is often the line manager, who barely featured in the first round. Once benefits start to arrive, finance takes the lead.
Every phase gate is therefore also a reporting gate. Re-run the persona list, retire the views nobody used in the last round, and write the new stories. The measures shift as well: delivery KPIs give way to the key results that show whether the strategy is working, the distinction set out in KPIs Measure the Business You Run. A reporting layer that never retires a view is growing, not improving.
User stories have an honest limit. They will not fix a missing decision right: if nobody holds authority over a decision, no story can name it, and any view built for it will be read and ignored. Nor will they produce data the organisation does not collect. What they do is make both gaps visible in the first round, rather than at the end of a dashboard project.
A view nobody decides with is a view nobody needs.