Act as an experienced Scrum Master helping me turn team evidence into a practical facilitation and improvement plan. Do not invent velocity, capacity, commitments, team agreement, or root causes. Team and product context: [TEAM CONTEXT] Current sprint evidence: [SPRINT EVIDENCE] Problem to address: [PROBLEM] Known constraints and dependencies: [CONSTRAINTS] People and decision owners: [OWNERS] Relevant working agreements or Scrum events: [WORKING AGREEMENTS] First, distinguish symptoms from plausible causes. Identify what would need validation in a retrospective, backlog refinement, stakeholder discussion, or delivery-data review. Avoid using Scrum ceremonies as status meetings or treating the Scrum Master as the owner of delivery work that belongs to the Product Owner or Developers. Produce a plan with: 1. A concise problem statement, success measure, and baseline drawn only from my evidence. 2. A table of actions for the next sprint: action, accountable owner, collaborators, timing, expected output, and evidence of completion. Include preparation, facilitation, and follow-through. 3. A detailed agenda for the one event most likely to surface or address the issue, with timeboxes, prompts, and an inclusive technique for quieter participants. 4. A dependency and escalation section: what the team can resolve, what needs Product Owner action, and what needs an organizational decision. 5. A risk register with early warning signs and a response that protects the sprint goal. 6. A short update I can send to stakeholders that reports facts, decisions needed, and next checkpoint without blaming individuals. Ask up to 3 clarifying questions only if a required input is missing. Before answering, check that every action has a named owner and observable outcome, and flag any metric that would reward output volume over a valuable sprint outcome.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [TEAM CONTEXT] | Describe the product, team roles, sprint length, maturity, and relevant operating environment. | Eight-person team building billing settings for a B2B SaaS product; two-week sprints; one Product Owner and six Developers. |
| [SPRINT EVIDENCE] | Provide concrete data and observations such as carryover, blocked items, flow time, or event attendance. | Last three sprints carried over 5 of 18, 7 of 20, and 6 of 17 items; most carryover entered after sprint start; three items waited on API review. |
| [PROBLEM] | State the delivery, collaboration, planning, or quality problem to solve. | The team starts too much work and discovers dependencies after committing. |
| [CONSTRAINTS] | List deadlines, technical dependencies, staffing limits, approvals, and external teams involved. | A customer-facing invoice release is needed by October 18; platform API team reviews changes twice weekly. |
| [OWNERS] | Name the Product Owner, delivery team leads, stakeholders, and decision-makers by role or initials. | PO: Maya; engineering lead: Devon; API liaison: Priya; release stakeholder: Finance Ops director. |
| [WORKING AGREEMENTS] | Share the relevant team norms, Definition of Done, sprint goal, or event format. | Sprint goal must be one sentence; Definition of Done includes API review and QA; daily Scrum is 15 minutes and not a reporting round. |
How to use
- Paste real sprint data and name decision owners by role, not just the issue you observed.
- Use the action table to confirm who owns each follow-up before the next sprint begins.
- Check that the agenda investigates a system condition rather than assigning individual blame.
- Follow up with: “Convert this plan into a Jira-ready checklist with one ticket per action and acceptance evidence.”
Variations
Retrospective agenda
Use when you need a focused retrospective on one recurring team problem.
Design a 60-minute Scrum retrospective around [PROBLEM]. Team context: [TEAM]. Evidence: [EVIDENCE]. Constraints: [CONSTRAINTS]. Create a minute-by-minute agenda with opening safety prompt, data review, divergence activity, cause-testing questions, prioritization method, and closing commitments. Include a remote-friendly participation method and specify who owns each follow-up. Do not declare a root cause unless the evidence supports it; list assumptions to validate during the session.
Sprint planning plan
Use before sprint planning to protect a clear sprint goal and avoid overcommitment.
Prepare a sprint planning plan for [TEAM] using this backlog and capacity information: [BACKLOG]. Sprint objective: [PRODUCT GOAL]. Capacity and absences: [CAPACITY]. Dependencies: [DEPENDENCIES]. Produce a planning agenda, a proposed sprint goal, questions to resolve before commitment, and a table classifying items as ready, needs refinement, or blocked. Include checks for Definition of Done, external reviews, and enough slack for urgent production work. Do not fabricate estimates or capacity.
Stakeholder update
Use when stakeholders need a concise, factual delivery update.
Draft a stakeholder update about [INITIATIVE]. Evidence since last update: [EVIDENCE]. Current sprint goal: [SPRINT GOAL]. Risks and dependencies: [RISKS]. Decisions needed: [DECISIONS]. Write 180 words with headings: Progress, Current Focus, Risks, Decisions Needed, Next Checkpoint. Separate facts from forecasts, name owners for decisions, and avoid blaming teams or promising dates that are not supported by the evidence.
Tips
- Use carryover, blocked time, unplanned work, and dependency age as conversation starters, then validate causes with the people doing the work.
- A sprint goal should describe the outcome or user value, not merely a list of unrelated backlog items.
- End every retrospective with one or two experiments that have an owner, a review date, and a signal that tells the team whether to keep them.
- Keep stakeholder updates focused on decisions and risks; detailed task status belongs where the delivery team already works.
FAQ
Can Copilot run a Scrum retrospective for me?
It can create an agenda, prompts, and follow-up structure. A Scrum Master still needs to read the room, protect psychological safety, and adapt during the discussion.
Should a Scrum Master assign all action owners?
No. The responsible person should agree to the action, while the Scrum Master makes ownership and review visible.
What if the team has no useful metrics?
Start with a small evidence set such as carried-over work, blocked items, and examples from the sprint. Do not invent a velocity trend to fill the gap.