Scrum Team Roles in Healthcare IT: Matrix Reporting, Daily Work, and BAT Sign-Off

Healthcare Scrum teams rarely look like the textbook picture. People join from different departments, report to different managers, and juggle production support while trying to finish sprint work. This article walks through the Scrum team roles on one healthcare IT team, then shows its backlog, planning, daily work, retrospectives, and business acceptance sign-off.

The Example: A Lab Results Release Team at a Health System

The team in this article is a composite of teams I have worked with at regional health systems. Names are invented. The work is typical.

The team owns “Results Release”: how lab results move from the lab system into the EHR, then out to the patient portal. The 21st Century Cures Act information blocking rule (45 CFR Part 171) pushes providers to release electronic health information to patients without unreasonable delay. The rule also defines exceptions, such as Preventing Harm and Privacy, where a delay can be justified. The team’s job is to turn that policy into working software, EHR configuration, and interfaces.

That mix of code, vendor configuration, and clinical policy is why the team needs every role below. Remove any one of them, and something important stops being checked.

Scrum Team Roles on a Healthcare Team: Who Is in the Room

The 2020 Scrum Guide defines only three accountabilities: Product Owner, Scrum Master, and Developers. Everyone who creates the increment counts as a Developer in Scrum terms. That includes the QE, the configuration analyst, and, during business validation, the BAT representative. The job titles below are organizational titles. Scrum does not care about them, but HR, budgets, and access controls do.

Count the managers. Nine people report to eight different line managers. None of those managers attends the Daily Scrum, and none of them should. That is normal for a matrix organization, and it is the source of most friction you will read about below.

Two Teams, Two Managers: How Matrix Reporting Works

Every person on this team has a home team and a Scrum team. The home team is the functional group: Integration Engineering, Clinical Applications, Laboratory Services, and so on. The Scrum team is the cross-functional delivery unit. Spotify popularized a version of this as “chapters” and “squads,” but hospitals ran matrix structures long before that label existed.

Who decides what: the split I put in writing

Where matrix conflicts show up

The worst conflict on this team came from the configuration analyst. Luis’s manager runs a production support queue for the whole lab module. When a result-routing issue hits a hospital at 2 AM, Luis gets the ticket. His sprint work stops. Without a pre-agreed buffer, the team discovers this at the Daily Scrum and the sprint goal slips.

The second conflict is the BAT representative. Priya’s director measures her on lab turnaround time, not on sprint delivery. During a flu-season surge, lab operations wins every time. That is the correct call for patients, so the team plans for it instead of fighting it.

The third conflict is quieter. Line managers write reviews but never see the sprint work. If the PO and SM do not send structured feedback, a developer’s best quarter can look invisible. Ray now sends each line manager a short contribution summary every Program Increment.

A Day in the Life of Each Scrum Team Role

Here is a typical Tuesday in week one of a two-week sprint. The Daily Scrum runs at 9:15 for fifteen minutes, as the Scrum Guide timeboxes it. Everything else in the day is shaped by which home team the person also serves.

What a useful Daily Scrum sounds like

The Scrum Guide frames the Daily Scrum around progress toward the Sprint Goal. It is not a status report to the Scrum Master. Here is a trimmed excerpt from this team.

Notice three things. Dependencies surfaced in under two minutes. The impediment went to the person who can remove it. The PO made a scope call on the spot, which keeps the team from overcommitting.

The Backlog: What a Healthcare Scrum Team Actually Works On

A healthcare product backlog holds far more than features. It carries configuration build, interface changes, compliance work, defects, and technical debt. The PO orders all of it in one list. Separate lists per home team are the fastest way to lose control of priorities.

The “BAT?” column matters more than it looks. It tells the team which stories need Priya’s time. On a 50% allocation, she can validate four or five stories per sprint, not ten. The PO orders the backlog with that limit in mind.

A realistic Jira story with role-specific sub-tasks

Two edge cases came up during story refinement. First, the 72-hour fallback was a policy choice by the health system, not a federal rule. The privacy officer had to approve it. Second, some genetic panels arrive as a single ORU message with mixed result types. The team split that into its own story instead of hiding it inside RR-214.

Backlog refinement: who brings what

The Scrum Guide treats refinement as an ongoing activity, not a formal event. This team holds two 60-minute sessions per sprint, on day four and day eight. Each role arrives with a different question, and the session fails if any one of them is missing.

Estimation happens here too. The team estimates config work in the same story points as code. Splitting config into hours while developers use points makes the sprint impossible to compare across iterations.

Definition of Ready and Definition of Done for a mixed team

The Scrum Guide calls the Definition of Done a formal commitment for the increment. The Definition of Ready is not in the guide. Many healthcare teams still use one, because a story without a policy reference or migration date will stall mid-sprint. Treat it as a team agreement, not a gate the PO must pass.

Sprint Planning With Partial Allocations

The Scrum Guide timeboxes Sprint Planning at eight hours for a one-month sprint. For two weeks, this team uses about three hours. The planning covers three questions from the guide: why the sprint is valuable, what can be done, and how the work will get done.

The two-week sprint calendar

Fixed dates matter more on a matrix team than on a dedicated one. Partially allocated people block their calendars weeks ahead. If ceremonies float, the BAT rep and config analyst miss them.

The Wednesday start is deliberate. Monday and Friday PTO is common, and a Wednesday start keeps planning and review away from long weekends.

Capacity math the team actually uses

Story points alone hide the real constraint, which is partial allocation. Ray runs a simple capacity sheet before planning. Each line manager confirms the allocation number two days ahead.

Formula: (Sprint days − PTO) × Allocation − Support buffer. Luis: (10 − 1) × 0.6 − 1 = 4.4. The downloadable kit calculates this automatically.

The bottleneck is obvious once the numbers sit side by side. Luis has 4.4 focus days and four stories need config. Priya has five days for BAT validation. The developers have more capacity than the team can convert into done work. Ray uses that gap to steer spare developer time toward RR-233, the tech-debt item that speeds up QE.

Sprint goal and edge cases from planning

Sprint 14’s goal: “Patients see a clear held-status for genetic results, and HIM can audit every hold.” RR-214 and RR-224 made the sprint. RR-221 did not. It needed a legal review of state minor-consent rules that had not finished.

Two planning constraints are specific to healthcare. EHR vendors often publish upgrade windows when configuration migrations freeze. The team checks the change calendar before committing any config story. Clinical go-lives also have blackout periods, such as the weeks around a new hospital opening. Committing work into a freeze is a planning defect, not bad luck.

Scenario: What Each Role Caught in Sprint 14

The sprint produced a working held-status feature. It also produced three defects, each found by a different role, which is the point of having all of them.

RR-247 is the defect that justifies a BAT representative from the lab. Corrected results happen every week in a busy lab. Nobody outside the lab thought to test them. Priya did, because she handles the phone calls when a correction confuses a patient.

The SQL the team used to verify holds

-- Held results: reason code present, hold duration within policy (SQL Server syntax)
SELECT  r.result_id,
        r.loinc_code,
        r.result_status,                 -- F = final, C = corrected
        h.hold_reason_code,
        h.hold_start_ts,
        h.release_ts,
        DATEDIFF(HOUR, h.hold_start_ts, COALESCE(h.release_ts, SYSUTCDATETIME())) AS hours_held,
        CASE
          WHEN h.hold_reason_code IS NULL                       THEN 'MISSING REASON'
          WHEN h.release_ts IS NULL
           AND DATEDIFF(HOUR, h.hold_start_ts, SYSUTCDATETIME()) > 72 THEN 'OVERDUE'
          ELSE 'OK'
        END AS audit_flag
FROM    lab_result r
JOIN    vs_genetic_loinc v   ON v.loinc_code = r.loinc_code
LEFT JOIN result_hold h      ON h.result_id  = r.result_id
WHERE   r.received_ts >= DATEADD(DAY, -14, SYSUTCDATETIME())
  AND  (h.result_id IS NULL OR h.hold_reason_code IS NULL
        OR h.release_ts IS NULL)
ORDER BY audit_flag, hours_held DESC;

Sam wrote the query. Priya ran it during BAT, and it surfaced RR-247 as a second signal: corrected results had no hold row at all. The HIM director now runs a scheduled version of this query weekly.

Sprint Review vs BAT Sign-Off: Not the Same Event

Teams mix these up constantly. The Sprint Review is a Scrum event where stakeholders inspect the increment and adapt the backlog. It is a working session, not an approval meeting. BAT sign-off is an organizational control. It records that an accountable business owner accepts the release against business rules and policy.

For a deeper look at how business acceptance differs from end-user testing, see this site’s comparison of BAT vs UAT.

The BAT sign-off flow this team uses

What goes into the sign-off record

Edge case: the Lab Ops Director is on vacation during the release window. Name a delegate in the working agreement before it happens. An unsigned record at CAB means the release waits, no matter how done the sprint was.

Sprint Retrospectives in a Matrix Team

The Scrum Guide timeboxes the retrospective at three hours for a one-month sprint. This team uses ninety minutes. The hardest part is not the format. It is that half the problems raised belong to someone outside the room.

Sample retrospective board from Sprint 14

Action items: inside the team vs outside it

Line managers do not attend the retrospective. People stop speaking honestly when the person who writes their review is in the room. Ray carries the outside-the-team items to the right manager within two days. He reports the answer at the next Daily Scrum, so the team sees that escalation works.

Dependencies Outside the Team: Scrum of Scrums and Change Control

No healthcare Scrum team ships alone. This team depends on the interface engine team for production routing changes and on the identity team for proxy-access rules. Every release also passes through a Change Advisory Board.

Ray attends a twice-weekly Scrum of Scrums with the other digital health teams. He brings one thing: dependencies that will block the sprint goal within five days. Status updates belong on the board, not in that meeting.

Change control shapes the calendar more than any Scrum event. Code deploys through the CI/CD pipeline after approval. EHR configuration moves through the vendor’s migration tool on a separate schedule. The team aligns both by scheduling every release candidate against the next config migration window. A release with code ready and config pending is not a release.

Edge case: an urgent regulatory change, such as a revised state reporting rule, can arrive mid-sprint. The PO decides whether it replaces sprint scope. If the change breaks the sprint goal, the PO can cancel the sprint, as the Scrum Guide allows. That happens rarely, but naming the option prevents a quiet overload.

Onboarding Someone Into Two Teams at Once

New team members get two onboarding plans, and most organizations only write one. The home team covers tools, standards, certifications, and access requests. The Scrum team covers the product, the backlog, working agreements, and the people.

In healthcare, access is the long pole. EHR build access often requires vendor training and certification. Test-environment logins need security approval. Lab system read access needs a separate request. I plan two sprints of reduced capacity for any new developer or analyst, and I start access requests before their first day.

Pair the newcomer with someone from a different home team for their first story. A new Java developer who pairs with the config analyst learns how results actually flow through the EHR. That knowledge is hard to get from documentation.

Common Mistakes With Scrum Team Roles in Healthcare IT

When I Would Use This Team Shape, and When I Would Not

I would not form this team shape for a pure EHR optimization backlog, such as order-set cleanup. That work is nearly all configuration. A Kanban team of analysts with a clinical informaticist moves faster there.

Tools Each Role Uses Day to Day

Defects from every role land in one Jira project with a shared workflow. If you need a refresher on statuses and hand-offs, the bug life cycle post walks through them.

Questions People Ask About Scrum Team Roles in a Matrix

Who does the developer actually report to: the Scrum Master or the line manager?

The line manager. The Scrum Master is not a people manager in the Scrum Guide’s model. The SM serves the team and removes impediments. Day-to-day work comes from the sprint backlog, which the Developers own.

Should the BAT representative be on the Scrum team or outside it?

On the team, even at partial allocation. Outside the team, the BAT rep sees stories only at the end, which is when rule defects cost the most. Inside, they shape acceptance criteria during refinement and accept stories during the sprint.

Is the configuration analyst a “Developer” in Scrum terms?

Yes. Scrum defines Developers as the people committed to creating a usable increment each sprint. Configuration is part of that increment. Excluding config from the Definition of Done creates “done” stories that do not work in the EHR.

What happens when two managers give conflicting priorities?

Sprint priorities come from the PO. Capacity limits come from line managers, set before planning. When a manager pulls someone mid-sprint, the SM records it, the PO adjusts scope, and the retrospective decides whether the agreement needs to change.

How does the team handle HIPAA in daily work?

Through the Definition of Done and test data rules. The HIPAA Security Rule requires audit controls for systems holding ePHI (45 CFR 164.312(b)). The team verifies audit logging per story and uses synthetic data in lower environments. Any exception goes through the privacy officer, not the team.

How long should sprints be on a healthcare team?

Two weeks works for most teams I have supported. The Scrum Guide allows up to one month. Longer sprints tempt teams to batch config migrations and BAT at the end. Shorter sprints rarely work when configuration has a weekly migration slot at best.

Does the BAT representative attend every Scrum event?

Not at 50% allocation. Priya attends Sprint Planning, refinement, the Sprint Review, and the retrospective. She joins the Daily Scrum on days she has BAT work in flight. The team agreed on this in writing, so nobody reads her absence as disengagement.

Write a Two-Manager Working Agreement Before Sprint 1

Before your next team forms, put each person’s Scrum team role, home team, line manager, allocation, and support buffer on one page. Have every line manager sign it alongside the PO and Scrum Master. That one page prevents most of the mid-sprint pull-aways, missed sign-offs, and invisible performance reviews described above.