Ceremonies

Our teams use 3 week sprints. This is our timeframe for planning, executing, and reviewing work.

Squad 1

The team has the following ceremonies:

Ceremony	Occurrence	Day	Time
Stand Up	Daily	Monday - Friday	10:00 - 10:15
Refinement	Weekly	Tuesday	11:00 - 12:00
Sprint Planning	Every third week	Thursday	10:00 - 11:00
Sprint Review	Every third week	Thursday	10:00 - 11:00
Sprint Retrospective	Every third week	Wednesday	10:00 - 11:00
Show & Tell	Every third week	Wednesday	15:00 - 15:30

Squad 2

Ceremony	Occurrence	Day	Time
Stand Up	Daily	Monday - Friday	-
Refinement	Weekly	Tuesday	-
Sprint Planning	Every third week	Thursday	-
Sprint Review	Every third week	Thursday	-
Sprint Retrospective	Every third week	Wednesday	-
Show & Tell	Every third week	Wednesday	-

Shared meetings

No shared meetings have been added yet.

Ceremony details

Stand Up

Our stand ups run daily at 10:00 and we aim for them to last for fifteen minutes. After updates, we have ‘parking lot’ time where team members can discuss any issues in more detail. Each team’s delivery manager usually runs stand up.

We use 2 formats for stand up:

Walk the board - starting with the “Done” column we discuss any active issues on our GitHub Project board
Round robin - each team member gives updates and raises any blockers

Backlog management

Backlog management is where we make sure our backlog is up to date and ready for refinement by:

Prioritising stories - give a clear picture of what the team is working on, and will be working on next
Removing stale stories - keep the team focused on only relevant work
Removing irrelevant stories - prevent the team’s focus from being split with work that’s not required

Process:

TBD in consultation with PM/DM.

Output:

A well prioritised backlog
A backlog that is ready for refinement and free of stale/irrelevant stories

Audience:

Product Manager
Delivery Manager
Leadership Team

Purpose:

Refinement is where each team gets an understanding and agreement of what we are working on in upcoming sprints. It’s where we ensure everyone has an understanding of the backlog items before they are added to a sprint.

Prerequisites:

Before we begin a refinement session, here’s what can be prepared:

Backlog Familiarisation - Review the backlog to get a sense of what’s coming up, and what’s already been done. Read the tickets likely to come up for discussion, so you know what questions you want to ask.
Backlog Items - Ensure any tickets have enough detail to be ready for discussion. This should include a detailed description of the story, as well as acceptance criteria.
Understand Dependencies - If your tickets rely on other work already being done, know which tickets are required and list them in the body of the issue. This helps us understand correct sequencing of tickets during refinement.
Prepare to communicate! - Be prepared to articulate why you think a ticket should be done, how big you think it is, and be receptive to teammates, and collaborate to achieve a shared understanding of the tasks at hand. Be open to suggestions on how your ticket could be improved for someone picking it up.

Process:

Preparation: Before refinement, the Product Owner picks out the stories that need our attention.
Discussion: Dive into the details of each story, hashing out the acceptance criteria, and spotting any dependencies or risks.
Estimation: Estimate based on effort and risk using a poker-scoring system, allowing the team to have a clear sense of the size and scope of each ticket.
Decomposition: Chop up any stories that are too big to handle in a sprint into smaller bits.
Definition of Done (DoD): Ensure each story has a clear DoD to know exactly when it is crossed the finish line.

Output:

Refined Backlog - Stories that are fleshed out, estimated, and ready for the Product Owner to prioritize
Scored Stories - Each story gets a score for a straightforward understanding of what we’re up against
Tickets Approachable - All tickets that go through refinement should have all the info required for any member of the team to pick up

Audience:

Each squad

Sprint Planning

Purpose:

Sprint Planning is where we figure out what work we want to commit to for the next sprint. It’s where we:

Discuss and align on the goals for the upcoming sprint
Select stories from the refined backlog, ensuring a shared understanding of scope and objectives
Define the sprint goal
Define the sprint backlog

Process:

Discussion: Discuss the stories in the refined backlog, ensuring a shared understanding of scope and objectives, including any work carried from last sprint.
Highlighting: Highlight stories and spikes that are significant to delivery of the sprint goal.
Capacity Estimation: Estimate the capacity of the team for the sprint, and assess whether the tickets brought in match that.
Sprint Backlog: Select the stories that will be brought into the sprint, and assign them to team members where appropriate.

Output:

Ensure everyone has stories that they feel they can work on
Ensure everyone has a shared understanding of the tasks to deliver this sprint

Audience:

Each squad

Sprint Review

Usually incorporated with sprint planning. A chance to discuss completed work to share knowledge within the team.

Audience - Each squad

Sprint Retrospective

Each squad has a retro at the end of each sprint. The retro format may be different for each sprint.

Reflect on the sprint’s process, celebrating successes and identifying opportunities for improvement
Review the process, not the stories
Define how we could improve
Share kudos and feedback

Audience:

Each squad

Show and Tell

At the end of each sprint we have a thirty-minute show and tell showcase to share with our colleagues and the wider organisation our achievements during the sprint The showcase normally consists of an introduction summing up the sprint and if we met our sprint goal followed by demonstration and then what’s next in the road map

Audience

All of Data Platform Services teams and wider audience

This page was last reviewed on 8 May 2026. It needs to be reviewed again on 8 May 2027 .