Agile ceremonies

Targets are not achieved alone - they need effective teamwork.
This page summarizes the working agreements on the Agile ceremonies.
So we make everyone's time worth while.

The rhythm behind real delivery.

Agile ceremonies are the structured moments that give teams clarity, focus, and alignment throughout each sprint.

They create a shared rhythm for planning work, inspecting progress, reviewing outcomes, and improving collaboration.

Each ceremony has a distinct purpose — plan, sync, inspect, demo, improve — yet together they create a continuous loop of adaptation and learning.

When executed well, Agile ceremonies boost delivery speed, team autonomy, stakeholder trust, and product quality.

What?

A structured set of recurring meetings that guide how teams plan, deliver, inspect, and improve their work.

Why?

To create predictable cadence, ensure alignment, enable rapid decision-making, surface issues early and foster continuous improvement - all while keeping the team laser-focused on delivering value.

Tip

If ceremonies feel like "meetings", reconnect them to their purpose. The goal isn't attendance - it's alignment, clarity, and momentum.

SPRINT PLANNING.

Sprint Planning sets the direction for the next sprint.

The ceremony aligns the team around a clear sprint goal, clarifies why the goal matters, and selects the backlog items needed to achieve it.

The team breaks down work, estimates effort, identifies dependencies, and ensures everyone understands what “done” means.

Good Sprint Planning avoids confusion, reduces mid-sprint chaos, and empowers teams to deliver with focus.

When done poorly, teams drift, goals collapse under conflicting priorities, and the sprint becomes a random to-do list instead of a purposeful iteration.

A planning session to define the sprint goal and choose actionable backlog items.

To align the team on focused objectives and create a realistic delivery plan.

At the start of each sprint (every 2 weeks).

A perfect story is a small, testable slice of user value with clear acceptance criteria, a clear purpose and no ambiguity.

New stories are created in the backlog , not related to a particular sprint.

A story must include:

  • User: Who? - The person who is responsible to complete this story.
  • Goal:  What? - The result that is intended to be achieved.
  • Value: Why? - The value that the result will create.
  • Acceptance criteria: The conditions that must be TRUE for the story to be considered completed. (verifiable, reviewable, unambiguous)
  • Size: How much? - The workload it will take to complete the story
  • Priority: How urgent is it?
  • Linked to a Feature (linked to an Epic): Why? on a higher level - The strategic target to which this story ads value.

Each team member:

  • Looks at the past sprint:
    • close every store that is allowed to close according the agreed acceptance criteria
    • are there stories of the past sprint that have to be transferred to the next sprint + what is the reason
  • Next objectives
    • How many workdays will you work in next sprint
    • Which feature(s) you want/need to work on
    • Which story/stories of that feature
    • Definition
      • Why is this needed for the next sprint?
    • Acceptance criteria to put this story to done
    • Story points (estimated time/workload
    • Make sure you plan a set of stories that fits your working time

Product Owner:

  • Run through the working power for next sprint (availability / working hours of each member)
  • Run through previous sprint
    • Check if all stories that are allowed to close according the agreed acceptance criteria are effectively closed
    • The "leftovers" 
      • Evaluate the reason why they were not closed in the previous sprint
      • Transfer them to the next sprint
  • Planning next sprint
    • Plan in "ceremony" time for each team member
    • Listen to the proposals for next sprint of each team member
      • Evaluate the priority and feasibility of the proposed stories
      • Check capacity
      • If accepted, put the story as "accepted" and link it to the next sprint
  • Evaluate the entire team's sprint
    • is it coherent
    • does it handle the priorities
    • are stories, left in the backlog, not treated in this sprint, of less priority?

Don’t just demo what you did — demo why it matters. Growth is not measured in features delivered but in value created and capability strengthened.

STAND UP (Daily Scrum).

The Daily Scrum keeps the team aligned and the sprint on track.

It is not a status meeting — it’s a brief tactical checkpoint to reassess progress toward the sprint goal.

Team members highlight what’s done, what’s next, and what’s blocking progress.

The purpose is transparency and adaptation, not reporting.

A strong Daily Scrum reduces surprises, accelerates collaboration, and keeps momentum high.

A 15-minute alignment to inspect progress, surface blockers, and adjust the plan for the day.

To adjust quickly, stay aligned, and keep the sprint goal front and center.

Every day of the sprint, at the same time.

Each team member:

  • Evaluate your stories
    • adjust statuses
    • Mark blockers to discuss them in the daily
  • If you receive a new not foreseen, urgent request during the sprint:
    • Create a story in the backlog (see Sprint Planning) and tag it as "unforeseen request"
    • Evaluate the impact on the planned User Stories
    • Discuss with the Product Owner if this stories can be accepted to be taken up in this sprint
  • Evaluate workload for the rest of the sprint:
    • are you able to complete all stories?
    • do you have some spare time to help others / tackle a backlog story?

Product Owner:

  • Discuss progress and obstacles
  • Discuss unforeseen stories:
    • how critical is it to been taken up in the current sprint
    • what is the impact if it is not
    • what is the impact for the other stories if it is
  • Discuss workload: someone in need of time/help or someone who has time to help other team members/tackle a backlog story?

If the Daily Scrum takes more than 15 minutes, you’re solving problems in the meeting instead of after it.

SPRINT REVIEW.

The Sprint Review demonstrates what the team actually achieved — not the effort spent, but the value created.

It’s an interactive session where stakeholders see working increments, ask questions, and provide feedback.

The goal is alignment and learning, and helps refine the product backlog based on new insights.

A strong Review builds trust, encourages transparency, and ensures the product evolves in the right direction.

A weak one becomes a monotonous slideshow nobody remembers.

A collaborative session to showcase the value delivered during the sprint and gather real stakeholder input.

To validate progress, refine expectations, and adjust the product direction.

At the end of every sprint, before the Retrospective.

Each team member:

  • Suggest your topic to the Product Owner: this can be an achievement, a success, a learning but also an obstacle you faced
  • Prepare your topic:
    • Tell a story, not a checklist
    • Add sprint evidence (metrics, screenshots, before/after comparisons, relevant learnings)
  • If you present a topic with more than 1 member: Brief internal roles.
    • Clarify who will
      • Introduce the goal
      • Present which increments
      • Answer stakeholder questions
      • Capture feedback

Product Owner:

  • Book a room to do the review and make sure everything is working (TV, etc.)
  • Evaluate the topics
    • Is it relevant?
    • Does it fit the timing? Make sure that the topics that will be discussed have enough time to do so.
    • Is everyone regularly getting his turn to present his achievements?

Lead = Product Owner

  • Start with the Sprint goal: Align everyone before diving into details
    • Sprint goal
    • Context
    • Why this mattered
    • Connection to product roadmap
  • Show only work that is Done, keep it tight and value-focused
    • What problem does this solve?
    • Who benefits?
    • What changed since last sprint?
  • Invite stakeholder feedback (the heart of the review)
    • Ask explicitly:
      • "Does this solve your problem?"
      • "Anything missing?"
      • "How does this affect your teams?"
    • Capture everything without debating immediately
  • Discuss what's next: the Review should shape the roadmap 
    • Share
      • Updated product backlog
      • Expected next sprint direction
      • Dependencies or risks discovered
  • Close with appreciation & clear follow-ups: a strong close increases clarity, trust, and momentum.
    • Summarize:
      • Key decisions
      • Action items
      • Feedback themes

  • Demo value, not widgets — focus on the impact, not the interface.
  • Show only Done items - half-baked work confuses everyone.
  • Don't make it a one-way presentation. If stakeholders don't speak, you didn't do a Review - you did a slideshow.

SPRINT RETROSPECTIVE.

The Retrospective is the team’s engine for continuous improvement.

It’s a protected space to discuss what went well, what went wrong, and what can be improved.

The team identifies actionable improvements and commits to trying them in the next sprint.

Retros aren’t blame sessions — they are structured, psychologically safe reflections designed to boost team maturity and performance.

When teams skip Retros, issues compound silently, collaboration degrades, and quality suffers.

Reflect on how the team worked and agree on improvements for the next sprint.

To strengthen teamwork, reduce friction, and improve delivery over time.

At the end of each sprint, at least every 2 sprints, after the Sprint Review.

Product Owner:

  • Gather data and signals from the sprint: so retro is grounded in facts, and opinions can be asked or challenged  
    • Sprint goal outcome
    • Bugs or quality issues
    • Lead / cycle time trends
    • Stakeholder feedback
    • Team sentiment signals
  • Prepare the space already at start of the sprint
    • Clean "What went well/ What didn't" board

 Each team member:

  • Fill in the board during the sprint, so you don't forget to mention it

Product owner leads, all team members contribute

  • Generate insights through observations
    • What went well ?
    • What didn't ?
    • What surprised us ?
    • Where did we lose time ?
    • Where did we create value ?
  • Group, Prioritise and Discuss the most impactfull topics (retros drown in noise without ruthless prioritisation)
    • Cluster similar insights
    • Vote
    • Discuss the top 2-3 items
  • Turn insights into 1-3 concrete improvement actions
    • Each improvement must be
      • clear,
      • owned,
      • feasible within the next sprint,
      • trackable
  • Close with appreciation and commitment
    • Final confidence check
    • Recap of actions and owners

If every Retro ends with 20 action items, commit to none — pick the 1 that matters most.

BACKLOG REFINEMENT.

Backlog Refinement ensures the team always has a healthy pipeline of well-understood, well-sized work.

It reduces planning stress, improves forecast accuracy, and gives the Product Owner a structured space to clarify priorities.

Refinement sessions focus on breaking large items into smaller ones, reviewing acceptance criteria, estimating complexity, and removing ambiguity.

Mature teams refine continuously rather than waiting for emergencies.

When refinement is skipped, Sprint Planning becomes chaotic and quality drops sharply.

An ongoing process to prepare high-quality, sprint-ready backlog items.

To ensure clarity, reduce uncertainty, and support predictable planning.
Objective is to decide together what are the must have User Stories for the relevant Sprint Planning.

Continuously; often 5% of the team’s capacity each sprint.

Each team member:

  • Alle stories are created in backlog (see Sprint Planning on how to create a story)
  • All stories that are no longer relevant, are removed from the backlog

Product Owner:

  • Run through the backlog
  • Identify stories that are 
    • unclear > ask to clarify
    • oversized > ask to split.
    • recurring > ask to split it accordingly per sprint (ex: Discovery Testing, PARP, CJE Run Activities etc.)

Product owner leads, all team members contribute

  • Start with the sprint goal pipeline
    • Focus on the items most likely to enter the next sprint
    • Refinement is about preparing for delivery, not reviewing everything
  • Clarify items to improve shared understanding
  • Define/ refine Acceptance criteria and Dependencies
  • Estimate story size
    • If too big > split it
    • If unclear > return to discovery
  • Finalize the backlog state (a clean backlog accelerates every other Agile ceremony)
    • Mark sprint-ready items (through tag)
    • Move unclear items back to discovery (through tag)
    • Remove or deprioritize outdated items
    • Document decisions
  •  

If your Sprint Planning feels painful, your refinement isn’t doing its job.

PERFORMANCE WALL.

A Performance Wall centralizes the most important metrics, insights, and signals the Tribe needs to make informed decisions.

It transforms performance data from something hidden in dashboards to something visible, shared, and actionable.

The wall helps teams monitor operational health, product value, customer satisfaction, delivery flow, and strategic goals.

A good Performance Wall turns raw numbers into meaningful discussions, reducing surprises and promoting a culture of transparency.

It is not decoration — it is a decision-making tool

A visual board showing the team’s most critical KPIs, insights, risks, and trends, used to drive informed conversations and immediate action.

To make performance visible, align the team around facts, trigger faster decisions, and create a culture where issues surface early instead of becoming crises.

Monthly update

Tribe Lead:

  • Select the KPIs that matter strategically

Product Lead/Owner:

  • Gather data and  ensure accuracy
  • Visualize clearly
    • Trends over time
    • Traffic lights
    • Threshold indicators
    • Simple charts
    • Clear titles
  • Prepare the narrative
    • What improved
    • What declined
    • What’s stable
    • What requires action
    • What decisions you need from the group

Tribe Lead:

  • Opens with purpose and context
  • Walks through the wall where every Product Lead/Product Owner explains his KPIs

Product Lead/Owner:

  • Discuss Not Just the What — But the Why (Observing data is easy; understanding it is where value happens.)
    • What happened?
    • Why did it happen?
    • What does it impact?
  • Turn insights into actions, owners and decisions:
    • What must we do?
    • Who owns it?
    • By when?
    • How will we track progress?
    • Close With a Summary & Next Checkpoint: create accountability and forward momentum

If the conversation focuses only on the numbers, you’ve missed the point — the wall exists to drive decisions, not admiration.

TALK THROUGH THE WEEK.

“Talk Through the Week” is a structured weekly touchpoint where the Tribe aligns on what happened, what’s coming, and what needs attention.

It creates shared context across roles, projects, and responsibilities.

Instead of scattered chats or reactive messaging, this session gives the team a predictable moment to look ahead, anticipate challenges, celebrate wins, and adjust priorities before work accelerates.

It prevents teams from drifting into silos or discovering issues too late. When done well, it boosts clarity, motivation, and cross-team coordination.

A weekly alignment ritual where the team shares announcements, priorities, risks, wins, and planned activities to start the week focused and connected.

To ensure everyone starts the week with the needed info and  same understanding of goals, focus areas, dependencies, and potential blockers.

At the start of each week

Tribe Lead / Product Area Lead:

  • Select the KPIs that matter strategically

Product Lead/Owner:

  • Collect info to share to the Tribe
    • Newcomers
    • Big achievements past week or upcoming week
    • Major things about to happen the upcoming week

Big impacts coming up next week (deliveries, etc. but for instance also strikes, etc.)

Tribe Lead / Product Area Lead

  • Lead the Talk
  • Let everyone speak

Be brief, bringing solutions and energy.

GROWTH ACHIEVEMENTS & DEMOS.

Growth Achievements & Demos is a ceremony designed to make progress visible — not just delivery output, but team learning, capability uplift, process improvements, and user-impactful changes.

It creates a shared moment to highlight wins, recognize contributions, and reinforce the behaviors that drive sustainable, high-performance delivery.

The ceremony includes demos of new features, insights gained, problems solved, and improvements made.

It encourages transparency, creates psychological momentum, and strengthens team identity and stakeholder trust.

When done well, it transforms “busy work” into visible value and fosters a culture of continuous growth.

A structured session where teams demonstrate achievements, product increments, and improvements — celebrating growth while aligning stakeholders to the value delivered.

To make progress visible, reinforce learning, motivate the team, engage stakeholders, and create a culture where improvement and achievement are recognized, not hidden.

Once / month.

Product Lead/Owner:

  • Identify Key Achievements Worth Showcasing
  • Reserve a slot in teh agenda of the Growth Achievements and Demos ceremony
  • Prepare Demo Material & Evidence
    • Screens, flows, prototypes
    • Before/after comparisons
    • Metrics improvements
    • Short stories from users or stakeholders
  • Select the Presenter(s)

Presenter:

  • Prepare the Narrative (Value > Features) - Stakeholders remember stories, not screens.
    • Problem → What was the pain or opportunity?
    • Action → What did we do?
    • Impact → Why does it matter?

  • Present: stand up in front of the audience
  • Tell a structured story
  • Demo: Show, don't tell
  • Share learning:
    • Technical lessons
    • Process insights
    • Customer feedback
    • Avoided pitfalls
  • Invite Questions, Reactions, and Suggestions
  • Close With Forward Momentum - Wrap up by summarizing:
    • Key achievements
    • Most important learnings
    • What’s next
    • Any open questions to resolve

Ending clearly reinforces alignment and confidence.

Don’t just demo what you did — demo why it matters. Growth is not measured in features delivered but in value created and capability strengthened.

Let's meet!

Let's take some time to get to know each other.
See if there is a click between us.
Who knows, together we can reach unprecedented heights.

Information

+32 478 93 11 15
info@usethegap.com
Enterprise nr: BE0799.672.849

Do you have questions?

Follow us