Agile ceremony quick reference
  • Sprint Planning: Commit to tasks; clarify scope, estimates, and acceptance criteria
  • Sprint Review / Demo: Show what was built; gather stakeholder feedback
  • Retrospective: Reflect on process; what went well, what to improve, action items
  • Backlog Refinement: Groom and prioritize upcoming tickets; break down large stories

Key principle: be specific — "unclear requirements" is better feedback than "communication was bad".

Sprint Planning

  • I estimate this will take about [X] points / days.
    Give a number — don't leave estimation open-ended
  • This task depends on [ticket / service / team] being ready first.
    Surface dependencies early
  • Can we break this story into smaller sub-tasks?
    When the ticket is too vague to estimate
  • What's the acceptance criteria for this ticket?
    Always clarify "done" before committing
  • I'd push back on the estimate — this is more complex than it looks.
    Honest re-estimation, not just agreeing
  • Let's reduce scope and ship the MVP — we can iterate after.
    Propose cutting scope, not quality
  • This is a spike — I need a few hours to investigate before estimating.
    "Spike" = time-boxed research task
  • I'm not confident in this estimate — there are too many unknowns.
    Flag uncertainty instead of guessing

Sprint Review / Demo

  • We completed [X] out of [Y] points this sprint.
    Velocity report — factual, no excuses yet
  • We didn't get to [ticket] — it's rolling over to the next sprint.
    Transparent about what was missed
  • Let me demo what we shipped.
    Simple and direct intro to the demo
  • This is still in progress — I can show the current state if useful.
    Offering a partial demo
  • Feedback from stakeholders was [positive / that we should revisit X].
    Summarise stakeholder input concisely
  • The scope changed mid-sprint, which impacted delivery.
    Explain (but don't over-justify) a miss

Retrospective

  • What went well: [we shipped on time / the deployment was smooth…]
    Start positive — be specific, not vague
  • What could be improved: [our code review turnaround / test coverage…]
    Focus on process, not people
  • One action item I'd suggest: [automating the release checklist]
    Concrete, actionable improvement
  • I'd like to raise the issue of [unclear requirements / context switching].
    Raise a systemic problem diplomatically
  • Let's keep doing [X] — it made a real difference this sprint.
    Reinforce what's working
  • I think we need to address [X] before it becomes a bigger problem.
    Frame issues as risks, not complaints
  • The root cause seems to be [process / communication / tooling] — not a people issue.
    Blameless framing
  • Can we timebox this retro item to 5 minutes and park the rest in a follow-up?
    Keep retro on track

Backlog Refinement

  • This ticket needs more detail before we can estimate it.
    Don't estimate vague tickets
  • Let's reprioritize — [bug / customer request] has come up since we last refined.
    Adjust backlog order openly
  • Can we add acceptance criteria before this goes into the sprint?
    Gate on clarity, not just priority
  • This is out of scope for this sprint — let's move it to the backlog.
    Firm but polite scope control
  • This ticket is blocked by [external API / design decision] — we can't start it yet.
    Flag pre-existing blockers in refinement
  • I'd like to split this into two tickets: one for the backend, one for the UI.
    Keep tickets small and independently shippable

Frequently Asked Questions

"What is the purpose of 'Triage' in a Sprint Ceremony?"

During a Sprint, 'Triage' refers to the process of assessing and prioritizing the Product Backlog items based on their value and urgency. The team identifies which stories are most critical for delivering immediate business value and focuses efforts accordingly, ensuring the Sprint remains aligned with strategic goals.

"Can you explain 'Definition of Ready' (DoR) within the context of Sprint Ceremonies?"

'Definition of Ready' establishes criteria that Product Backlog items must meet before they can be pulled into a Sprint. This ensures stories are well-defined, have sufficient detail for development, and are testable, minimizing rework and maximizing sprint efficiency.

"What does 'Burndown Chart' visually represent during a Sprint Ceremony?"

A Burndown chart graphically illustrates the remaining effort in a Sprint over time. It shows how quickly the team is completing work, highlighting potential roadblocks or areas where progress might be slower than anticipated, promoting proactive adjustments.