Hospital Data Platform scenario walkthrough

A dashboard can pass every test and still be wrong. That sentence is the whole scenario. Hospital Data Platform is about the gap between work that demonstrates well and work that is true, in a setting where a wrong number can send a bed manager to the wrong ward.

The project

Brightwater General needs bed-occupancy and wait-time dashboards before winter pressure begins. The budget is $108,000, the time is sixteen weeks and the plan is five sprints. The code the team writes works on clean samples. The real data, from the admissions system, does not look like the samples.

The backlog shows where the effort really goes. Agree read-only access and a masked extract. Load admissions, transfers and discharges every night. Clean duplicate records and missing timestamps. Agree one definition of an occupied bed. Only then come the visible parts: beds occupied now by ward, the seven-day trend, the time from arrival to first assessment, the current wait by triage level and waits against the hospital's own target. And the quiet ones that decide whether any of it can be trusted: checks on every load for missing and impossible values, alerts when a load fails, a data-quality badge on every dashboard, and hiding small counts.

Notice the order of difficulty. The least visible work is the work that has to happen first.

Demoable is not done

The four outcomes on the scenario card are separate "demoable" from "done" when data quality is the risk, make invisible but essential work visible to a sponsor, treat metric definitions as requirements, and run honest demos on real data.

Metric definitions are requirements. What counts as an occupied bed? A bed with a patient discharged an hour ago, or one being cleaned? Two reasonable people give different answers, and the dashboard will show one of them. The scenario treats the definition as something that needs agreeing, writing down and checking, as much as any user story. Acceptance criteria cover how to make such a statement checkable.

Invisible work needs a voice. The sponsor asks what is visible, and a good deal of the valuable work is not. The Scrum Master's job in this scenario includes making it visible, in numbers the sponsor can read. That is the Increment stretched: usable and verified, including parts nobody will ever see.

Real data in the demo. An honest review shows the platform on real extracts, including the parts where it fails. A demo on clean sample data is easy to give and tells the audience nothing about the winter.

The people

The sponsor is the chief operating officer, a physician by training, who ran the extra-bed programme last winter and opened the beds a week late. She trusts what she can check. She sees data-quality work as a cost she cannot show anyone, and asks what is visible. She is fair: shown a gap in the data and its cost, she will back the team, but she needs to see it as a number.

The team, played by AI unless you take the role:

• The Product Owner leads bed management and has a nursing background. He knows how a ward counts a bed better than anyone and the data less well, so a definition he thought was settled lands as news.
• The Scrum Master, when it is not you, makes the invisible work visible and keeps the review about what is true, not about what looks good.
• The analytics lead will not call a number done until its definition is agreed, its check has run and it has been compared with the real extract.
• The dashboard developer tests with charge nurses on night shift and says when a chart shows more certainty than the data has.
• The data engineer knows how the admissions extract is built, and how often it changes without warning.

The phases

Phase 1 moves from the business case and a needs survey, which asks what charge nurses and the board each need from the dashboards, to the sprint length. In the epics workshop, the wish for visible dashboards meets the less visible work underneath.

The epics list that results has an unusual shape: ingestion and data-quality checks sit among the dashboards, each with a value and a risk.

Phase 2 turns the top of the backlog into a sprint. You check the stories, run planning poker, break the work into tasks and freeze the sprint backlog. Estimating work with uncertain data is the hard part, and story points and planning poker are the techniques you will use.

Phases 3 and 4 repeat for each sprint. Blockers, risks and mid-sprint requests arrive, and at each review you decide what meets the Definition of Done. Risk in Scrum describes why a risky item belongs early in the order.

Phase 5 is the cutover, the agreement on the working deliverables and a retrospective on the whole project. A scorecard follows, built from the decisions you recorded. It is a scorecard and not a certificate.

Questions to carry into it

Prompts to keep beside you while you play. None has a hidden answer.

• Could two sensible people read this number differently? If so, the definition is a requirement, and someone has to own it.
• What would the dashboard say if the load failed overnight? A number that looks fine when the data is missing is more dangerous than an obvious error.
• What does the sponsor see, and what do they not? The quiet work is only valued if someone makes it legible.
• Would the charge nurse trust this at four in the morning? The people who use the dashboards are tired and busy, and they will not forgive a wrong count twice.

This is the scenario where the least glamorous items in the backlog carry the most weight. Learning to say so, in numbers, is most of the point. A sponsor who can see that a load failed three times last week, and what that would have meant for the dashboard, is far more willing to protect the time spent on checks than one who has only been told they matter.

Who it suits

The card says it is for experienced learners who want to see Scrum under data uncertainty, and recommends Logistics API first. The active work is estimated at about four and a half hours, spread over many days.

What each role takes from it:

• Scrum Master: making invisible work visible, and keeping the review made of what is true.
• Product Owner: telling a senior sponsor that the least visible work has to go first.
• Developer: saying what you find in the data the moment you find it, and refusing to load what you have not checked.

The other scenarios are in the scenarios at a glance. Hospital Data Platform is fictional, as are Brightwater General, its people, its data and the figures. It is a training scenario and not clinical or operational advice.