ScrumC#

What is ScrumC#

ScrumC is confirm-flavoured Scrum. It’s basically Scrum, but our goals & objectives also play an important role.

ScrumC guidelines#

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

  • We maintain our PB, epics & US in GitLab issues

  • Our sprint length is 2 weeks

  • There’s are short dialy meetings

  • There are longer meetings will be held bi-weekly

  • All employees must be present in the office

  • Meeting lead has dbarton, with rbrem as backup

  • The calendar invitations are provided via our ICS service

  • The meetings have a hard time boxing

  • PO’s are dbarton & rbrem

  • We’ve no dedicated SM’s

  • Language is always English

Important

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

Definition of ready (DoR)#

  • The PBI is written as formal US (i.e. “As a {kind of user} I want {feature} so that {benefit}”)

  • The business value is clearly articulated

  • The PBI is understood by the team

  • AC’s are sufficiently defined and understood by the team

  • Dependencies are identified

  • No external impediments can block the PBI

  • The PBI is estimated by the team

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

Definition of done (DoD)#

  • All AC’s are complete

  • Automated tests for all AC’s are defined and run successfully (where applicable)

  • The changes are merged into master

  • 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 team had a demo of the changes

  • The time spent is updated

ScrumC workflow#

We’re using the following ScrumC workflow:

Preparation
PO's & GL/OL optional
Pre-Planning

On the pre-planning meeting, the PO's create a draft for the next sprint.

This means the PO's create US' and assign them to the next SBI.

product backlog
move into sprint backlog
Refinement

On the refinement meeting, the PO's refine all SBI as ready as possible.

If a GL or OL needs resources assigned to achieve a target, this needs to be addressed here.

Planning
in the team
Planning

The rest stays unassigned and resides in the SB.
US' will be assigned & planned into the sprint until the team's capacity is reached.
The team will give a commitment on the US‘ and they will be marked as ready.
On the planning meeting, the PO's prioritise the US' of the SB.

ScrumC ready
to do
plan into sprint
Sprint
individual
Sprint

The assignee starts working at a US (to do in progress).

When the assignee is finished, the US is updated (in progress > to review).

todo
in progress
to review
Review
in the team
Review Meeting

Unfinished US' will be closed and for the remaining work a new US is created by the assignee.
Assignees demonstrate finished and reviewed US' to the rest of the team.

to review
close

ScrumC meetings#

Daily#

The daily meetings take 15 minutes from 09:45 until 10:00. Each team member will answer the following questions in front of the team:

  • What did I plan for today?

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

  • Am I blocked or are there any impediments?

  • Do I need any help from anybody?

  • Do I have enough US’ for the rest of the Sprint?

  • Do I have any absences within the next week?

  • What are my goals with the planned tasks for today?

  • Did I achieve my goals from yesterday, if not, why not?

Review#

The review meeting takes 30 minutes and the goals are:

  • Look back on the last sprint

  • Identify what we achieved

  • Update the team on ongoing US’

  • Demonstrate finished US’ to the team

  • Close finished & demonstrated US’

Important

For the review meeting, US’ 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 his/her US’ to a representative.

Retrospective#

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

  • Look back on the last sprint

  • Identify unplanned US’ and find out why we’ve had them and how we can avoid them

  • Identify spill over US’ and find out why we’ve them and how we can avoid them

  • Identify impediments and find out how we can avoid them

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

  • Finished & demonstrated US’ will be closed

  • Untouched (i.e. to do) spill over US’ will be moved back into the PB or the next SB

  • Touched (i.e. in progress) spill over US’ will be closed and new US’ with the incomplete tasks will be created in the PB or next SB

  • The SB is 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 notes app.

Refinement#

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

  • Look ahead on the next sprint

  • Identify objectives & goals which need to have resources assigned in the next sprint

  • Find, write and refine the required US’ for the next sprint

  • Make sure US’ are ready according our DoR

Basically prepare the next SB and identify the most important US’.

Important

This is usually done by the PO’s. However, goal & objective leaders can/should/must also pro-actively attend to this meeting if they need resources in the next sprint.

Planning#

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

  • The planning of the next sprint

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

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

  • Each planned US must be moved from the SB into the to do state

  • Each planned US must be assigned to a user

Basically just assign & move some US’ from the SB into the to do swimlane.

ScrumC GitLab issues#

  • Epic’s are maintained as GitLab issues and are labelled with the ScrumC epic label

  • US’ are maintained as GitLab issues and are labelled with the ScrumC US label

  • US’ ready for planning are labelled with ScrumC ready

  • US’ which were unplanned but worked on during a Sprint are labelled with ScrumC unplanned

ScrumC terms#

Product Backlog

PB

Product Backlog Item

PBI

Sprint Backlog

SB

User Story

US

Acceptance Criteria

AC

Definition of Ready

DoR

Definition of Done

DoD

Product Owner

PO

Scrum Master

SM

Objective Lead

OL

Goal Lead

GL