ScrumC

What is ScrumC?

ScrumC is confirm-flavoured Scrum. It’s a lightweight variant of Scrum, in which our OKRs also play an important role.

ScrumC guidelines

General ScrumC guidelines

  • We’re maintaining a Scrum light approach rather than an all-in approach

  • We maintain our backlogs, epics & stories in GitLab work items

  • Our sprint length is 2 weeks

  • There are short daily meetings

  • Longer meetings are held bi-weekly

  • All employees must be present in the office on the bi-weekly meeting day

  • Meeting lead is dbarton, with rbrem as backup

  • The backlogs are maintained by the captains, i.e. the product captain & service captain

  • The calendar invitations are provided via our Calendar subscriptions

  • The meetings have a hard time boxing

Important

When the meeting day is a holiday or similar, the meetings will be postponed to the next workday.

Definition of ready (DoR)

  • The story is written informally

  • The business value is clearly articulated

  • The story is understood by the team

  • Acceptance criteria are sufficiently defined and understood by the team

  • Dependencies are identified

  • No external impediments can block the story

  • The story is estimated by the team

  • The story is small enough to be completed in one sprint

Definition of done (DoD)

  • All acceptance criteria are complete

  • Automated tests for all acceptance criteria are defined and run successfully (where applicable)

  • The changes are merged into main

  • The changes are deployed on a testing environment

  • The changes did not break the CI/CD pipeline

  • The documentation is updated and the team knows where to find it

  • The changes were presented to the team in the review meeting, with a demo where planned

  • The time spent is updated

ScrumC workflow

We’re using the following ScrumC workflow:

Preparation
Captains & OKR leads optional
Preparation

In advance, the captains create a draft for the next sprint.

This means the captains create stories, prioritise and assign them.

product backlog
prioritise
assign
Refinement

In the refinement meeting, the captains refine all stories as ready as possible.

If an OKR lead needs resources assigned to achieve an OKR, this needs to be addressed here.

Planning
in the team
Planning

Stories will be planned into the sprint until the team's capacity is reached.
The team will give a commitment on the stories, and they will be marked as planned.

State: Ready
State: Planned
Sprint
individual
Sprint

The assignee starts working on a story (planned doing).

When the assignee is finished, the story is updated (doing review / demo).

State: Planned
State: Doing
State: Review
State: Demo
Review
in the team
Review Meeting

Assignees present their finished stories to the rest of the team.
Stories in the demo state are shown in a short demo, stories in the review state are only mentioned.

State: Review
State: Demo
close

GitLab work items

Story lifecycle

Stories are maintained as GitLab work items and are labelled with the Item: Story label.

The lifecycle of a story is like this:

  1. State: Ready: When the story is ready (see Definition of ready (DoR))

  2. State: Planned: When the story is planned in the sprint

  3. State: Doing: When the story is worked on

  4. State: Demo or State: Review: When the story is finished and will be presented in the review meeting

    • State: Demo: The assignee shows a short demo

    • State: Review: The assignee only mentions it, no demo is planned

There are also flags, which highlight special stories and help us to identify issues in our process during the retrospective:

  • Flag: Ad-hoc: When the story wasn’t planned, but created / scheduled mid-sprint

  • Flag: Ongoing: When the story isn’t expected to be completed in a single sprint (i.e. expected spill-over)

  • Flag: Blocked: When the story is blocked (e.g. through impediments, missing resources or an outage)

  • Flag: Critical: When the story is critical and requires special attention

  • Flag: AI: When the story was created by the AI, respectively via Glancelot

See also

To see all available labels, check out our GitLab labels.

Epics

Epics are maintained as GitLab work items and are labelled with the Item: Epic label.

OKR items

OKRs are maintained as GitLab work items and are labelled with the Item: OKR label. They’re displayed in our roadmap.

ScrumC meetings

Daily

The daily meetings take 15 minutes. Each team member will answer the following questions in front of the team:

  • What did I plan for today?

  • Did I have any issues yesterday with the planned tasks?

  • Am I blocked or are there any impediments, and are those stories flagged with Flag: Blocked?

  • Do I need any help from anybody?

  • Do I have enough stories for the rest of the sprint?

  • Do I have any absences within the next week?

Refinement

The refinement meeting takes 30 minutes, and the goals are:

  • Look ahead on the next sprint

  • Identify OKRs which need to have resources assigned in the next sprint

  • Find, write and refine the required stories for the next sprint

  • Make sure stories are ready according to our Definition of ready (DoR)

In short, prepare the next sprint and identify the most important stories.

Important

This is usually done by the captains. However, OKR leads must also pro-actively attend this meeting if they need resources in the next sprint.

Planning

The planning meeting takes 30 minutes, and the goals are:

  • The planning is made according to the priorities of the refinement meeting

  • Stories are planned into the sprint until the team’s capacity is reached

  • Each planned story must be moved from the ready into the planned state

  • Each planned story must be assigned to a user

In short, assign & move some stories from the backlog into the planned state.

Review

The review meeting takes 30 minutes and the goals are:

  • Look back on the last sprint (e.g. with our Retro tool box)

  • Identify what we achieved

  • Update the team on ongoing stories

  • Demonstrate stories in State: Demo to the team, and mention the ones in State: Review

  • Close finished & presented stories

Important

For the review meeting, stories must’ve been reviewed by a second party. This must happen during the sprint and the assignee is responsible to get the review done.

Important

If there’s an absence of a team member, the team member (aka assignee) must refer their stories to a representative.

Retrospective

The retrospective meeting takes 30 minutes, and the goals are:

  • Look back on the last sprint (e.g. with our Retro tool box)

  • Identify ad-hoc stories and find out why we’ve had them and how we can avoid them

  • Identify unexpected spill-overs and find out why we’ve had them and how we can avoid them

  • Identify impediments, e.g. by stories flagged with Flag: Blocked, and find out how we can avoid them

In this meeting, all stories of the sprint will be updated accordingly. This means:

  • Finished & demonstrated / reviewed stories will be closed

  • Untouched (i.e. planned) spill-over stories will be moved to the next sprint

  • Touched (i.e. doing) spill-over stories will be closed and new stories with the incomplete tasks will be created in the next sprint

  • Ongoing stories flagged with Flag: Ongoing will simply be moved to the next sprint

Important

Apart from the typical Scrum retrospective, we also do a team retrospective. In the team retrospective, we answer the following questions:

  1. Are there any highlights?

  2. Are there any potential improvements?

We collect and cluster these inputs by leveraging our Noddl app.