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. .. _Scrum DoR: 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 .. _Scrum DoD: 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: .. raw:: html
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 :ref:`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 | +----------------------+-----+