scrum_team_coaching v1.0.0

name: "scrum_team_coaching" description: "Coach a Scrum team back to health: read sprint and flow data for anti-patterns, run refinement and retrospectives that produce experiments instead of complaints, clear impediments with named owners, and advise on scaling only when the single team works. Use when a Scrum team keeps carrying work over, misses its Sprint Goal, drowns in unplanned work, runs flat retrospectives, or is being pushed to scale before it is ready."

Scrum Team Coaching

Purpose

Take a struggling Scrum team and find the smallest set of changes that make its Sprints work again. The method is data first, blame never: export the last three to six Sprints, run the health worksheet, match the numbers to what the events actually look like, then coach one or two experiments at a time until the numbers move.

This skill is grounded in the 2020 Scrum Guide by Schwaber and Sutherland, the Scrum.org flow metrics from the Kanban Guide for Scrum Teams, Evidence-Based Management, and the Nexus Guide for scaling. Where this skill sets a numeric threshold, that threshold is a coaching heuristic from this skill, labeled as a flag to investigate. It is not a standard and never a score to punish a team with.

Use it for a single Scrum team first. The scaling section applies only after that team reliably produces a Done Increment.

Workflow

1. Get the data before forming an opinion

Ask for a per-item export of the last three to six Sprints with these fields: Sprint, item id, status (Done, carried, dropped), points if the team estimates, cycle days from start to Done, blocked days, whether the item entered after Sprint Planning, and how many items were in progress on day one. Jira, Azure DevOps, Linear, and a hand-kept spreadsheet can all produce this shape.

Save it as a CSV in the worksheet format and run the calculator:

python3 scripts/sprint_health.py assets/sample-sprint-export.csv

The script reports per Sprint and overall: items Done and carried, carryover rate, points planned against points Done from the plan, throughput in items, average and 85th percentile cycle time, blocked days, unplanned share of Done, and heuristic flags. The 85th percentile cycle time doubles as a candidate Service Level Expectation, stated plainly as: 85 percent of items finished within N days, based on the team's own history.

Rules for the data step:

• Count Done only when the item met the Definition of Done. Half finished counts as carried, at full honesty, not as partial credit.
• If the team cannot export cycle days or blocked days, start the worksheet anyway with what exists, and make adding those two fields the first data fix. Never invent numbers to fill a gap.
• Keep every measure at team level. The worksheet has no per-person fields on purpose.

2. Read the worksheet for patterns, not incidents

One bad Sprint is weather. The same signal in two or more Sprints is a pattern worth coaching. Work through these reads in order:

• Carryover: at or above 25 percent in two or more Sprints points at item size, late starts, or end-of-Sprint testing pileups. Check whether the carried items share a size class or a dependency.
• Flow: the four flow metrics are Work in Progress, Cycle Time, Work Item Age, and Throughput. Little's Law links three of them: average cycle time equals average WIP divided by average throughput (Little, Operations Research, 1961). If WIP at Sprint start exceeds what the team finishes in a Sprint, long cycle times are arithmetic, not effort.
• Unplanned work: at or above 30 percent of Done means the Sprint Goal is competing with interrupt work and usually losing.
• Blocked time: five or more blocked days in a Sprint, or the same blocker across Sprints, means impediments are being noted and not cleared.
• Tail: an 85th percentile cycle time at least twice the average means a few items age while most flow. Work item age, checked daily, catches those items while there is still time.

Match each pattern against references/anti-pattern-catalog.md. A pattern is named to the team only when the data signal and the room signal agree: what people see in the Daily Scrum, refinement, review, and retrospective matches what the numbers say.

3. Check the framework basics before inventing fixes

Many sick teams are missing a basic the Scrum Guide already defines. Check these five before proposing anything new:

• Sprint Goal: the Sprint Backlog has one, it is a single outcome, and the team can state it the same way. The Sprint Goal is the commitment of the Sprint Backlog.
• Definition of Done: it exists, it is written, and Done items meet it. It is the commitment of the Increment.
• Product Goal and an ordered Product Backlog: the Product Owner can state the Product Goal, and the top of the backlog is ordered by value, not by who shouted last. The Product Goal is the commitment of the Product Backlog.
• Events at full strength: Sprint Planning covers why, what, and how within its timebox, the Daily Scrum is a 15 minute Developers event focused on progress toward the Sprint Goal, the Sprint Review inspects the Increment with stakeholders, and the Sprint Retrospective concludes the Sprint. Shorter Sprints use shorter timeboxes in proportion.
• One Product Owner, one Scrum Master, Developers, typically 10 people or fewer in total, cross-functional and self-managing.

A missing basic gets fixed as itself. A team with no Sprint Goal does not need a new tool, it needs a Sprint Goal.

4. Coach refinement so items arrive small and ready

Refinement is where carryover is prevented, weeks before planning feels the pain. Run it as a regular working session, not a status meeting.

• Work the top of the backlog, enough for about two Sprints ahead.
• Break down and define items into smaller, more precise items, adding description, order, and size, per the Scrum Guide description of refinement.
• Apply the ready test from the Guide: an item is ready for selection when the team believes it can be Done within one Sprint. If the honest answer is maybe, split it. Split by workflow step, data variation, user type, or happy path first.
• Name dependencies out loud and write them on the item. A dependency discovered mid-Sprint was usually visible in refinement.
• End each session by listing the items that failed the ready test, with the gap and a named owner to close it.

5. Run retrospectives that produce experiments

Follow references/retro-experiments.md. The shape that works: open by reading the last experiment and its result, put worksheet facts on the wall before opinions, pick one theme by vote, trace it to a cause the team controls, and write one experiment card with a hypothesis, an owner, a measure, a guardrail, and a review date. Cap the team at one or two experiments per Sprint and add them to the next Sprint Backlog, which the Scrum Guide explicitly allows for the most impactful improvements.

Complaints that point outside the team do not become experiments. They go to the impediment log in step 6, with evidence from the worksheet attached.

6. Clear impediments with owners and dates

Keep one impediment log, visible to the team and to the people who can act on it. Four fields per entry: impediment in plain words, owner (a named person, and for blockers outside the team that person sits outside the team), date raised, escalation date. The Scrum Master owns the log, not the impediments.

• Review open entries in the Daily Scrum when they touch current Sprint items, and in every retrospective until the repeat blockers shrink.
• Escalate on the date written down, with worksheet evidence: blocked days, ageing items, Sprints affected. Evidence gets a hearing that frustration does not.
• Close an entry only when the blocker is gone in the data, not when a meeting about it has happened.

7. Advise on scaling only when the single team works

Scaling advice starts with a gate. Do not recommend adding teams, layers, or coordination roles while the single team shows carryover, ageing, or blocker patterns, because more teams multiply dependencies and hide the original problem behind coordination work.

When the gate passes, meaning the team reliably produces a Done Increment that meets its Sprint Goal, and a real capacity need remains, present Nexus as the reference option and describe it accurately:

• A Nexus is 3 to 9 Scrum Teams working on a single product, with one single Product Backlog and one Product Owner.
• The Nexus Integration Team, made of the Product Owner, a Scrum Master, and Nexus Integration Team Members, is accountable for delivering a valuable, useful Integrated Increment at least once every Sprint.
• A Nexus Sprint Backlog makes cross-team work and dependencies transparent during the Sprint, and a Nexus Sprint Goal sets the objective for the Sprint.

Name the other routes honestly as alternatives the organization may weigh, and keep the coaching point in front: scaling spreads whatever the single team already does, good or bad.

8. Close the loop with value, not output

Once delivery stabilizes, shift the coaching conversation from output to value using Evidence-Based Management, the Scrum.org framework updated in 2024. Its four Key Value Areas are Current Value, Unrealized Value, Ability to Innovate, and Time to Market. Pick one measure per area with the Product Owner, review them at the Sprint Review, and let them set the next round of experiments. Velocity stays out of this conversation: it is a planning input for the one team that produced it, and Scrum.org guidance calls it a poor measure of value creation.

Output Contract

A coaching engagement with this skill produces, in order:

1. The sprint health worksheet output for the last three to six Sprints, with the raw CSV kept beside it.
2. A diagnosis that names each confirmed pattern, the data signal and the room signal behind it, and the catalog entry it matches. Patterns with only one signal are listed as suspects, not findings.
3. The framework basics check from step 3, with each of the five items marked present, partial, or missing.
4. One or two experiment cards in the format from references/retro-experiments.md, placed in the next Sprint Backlog.
5. An impediment log with owner and escalation date on every open entry.
6. A scaling note only when asked: gate verdict first, then the Nexus description if the gate passes.

references/worked-diagnosis.md shows all of this on a worked three Sprint example, using the bundled sample export and the actual script output.

Operating Rules

• Never use worksheet numbers to rate individuals or compare teams. Say this plainly whenever a manager asks, and refuse to produce a per-person cut of the data.
• Never extend the Sprint to protect a forecast or a velocity number. Sprints are fixed length, one month or less, and the next Sprint starts immediately. Reduce the forecast instead.
• Never plan or coach to 100 percent of capacity. Unplanned work always arrives, and a Sprint with no slack turns the first surprise into carryover.
• Present flags as questions. The thresholds in the script are heuristics from this skill, and a flag opens a conversation with the team, it does not close one.
• Keep the team's data with the team. Share worksheet results outside the team only in aggregate and with the team's knowledge.
• One fix at a time beats a transformation plan. If the team cannot state the current experiment and its measure, there are already too many changes running.
• Cite the Scrum Guide for framework claims and Little's Law for flow claims. If a recommendation is coaching judgment, label it as judgment.