Scrum
===

###### tags: `SCRUM`

# Table of Content

[Toc]

# What is this document?

This document outlines our way of utilizing the **SCRUM** framework to maximize developer productivity, and make sure that we deliver a **Potentially Shippable Product Increment** at the end of each sprint!

:::info
Note that even though some SCRUM terms will be explained as part of the context, this document is not a SCRUM guide, it's simply a manifest of our own processes in accordance with SCRUM. :wink:
:::

# What is SCRUM?

> Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
> -- www.scrum.org

SCRUM is a lightweight framework that focuses on allowing the development team (us) to maximize performance, and to ensure that we can deliver working software fast and consistently that provides value to the company. It comes with a set of rules (like a set of meetings with set time-boxed duration), but does not cover any development practices.

# SCRUM roles

* Product Owner: Søren Spelling Lund
* Maximizing the value of the product by prioritizing the backlog based on the value it generates for the company.
* Development Team
* A self-organizing team of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.
* Scrum Master: David Kelemen
* Responsible for promoting and supporting Scrum by helping everyone understand Scrum theory, practices, rules, and values. Also a facilitator of the scrum ceremonies.

The collection of the above 3 is the SCRUM team.

# Sprint

> A Sprint is is a time-box of one month or less during which a "Done", usable, and potentially releasable product increment is created. A new Sprint starts immediately after the conclusion of the previous Sprint.
> – www.scrum.org

- Our current agreed sprint length is **3 weeks**.
- For each sprint, we commit to developing a working product increment (discussed later).

Anatomy of a sprint (most item from below will be explained later):

# Potentially shippable product increment

> The increment must be in usable condition regardless of whether the Product Owner decides to release it.
> – www.scrum.org

This is the outcome of **each and every** sprint. It is the result of all efforts during the sprint (Coding, writing documentation, testing etc.).

This means, what we get out of the sprint must at all times be complete and the entire scrum team must feel confident in being able to release it in production.

# Sprint planning

**Who attends:** Scrum Team
**Duration:** Time-boxed for 3 hours
**Time:** First day of the sprint

## Inputs

* Prioritized Product Backlog
* Previous Product Increment
* Team velocity
* Team capacity for the next Sprint

## Topics

**The What**
* The Product Owner introduces the highest priority Epics from the Product Backlog.
* What will been done in this Sprint
* Product Backlog Items (PBIs) selected from the Product Backlog. Solely the decision of the Development Team.
:::success
Dev team selects a representative, who will control the mouse and drag & drop selected stories into the sprint and create the development tasks. (not the PO, not the SM)
:::
* Based on the Epics selected, define a Sprint Goal
* 1-2 sentences
* Discuss and estimate* each story.

\* To begin with, we won't be estimating stories. Instead we'll use story count as our measure for velocity. We'll see how well this works, and then we'll adapt as necessary.

:::info
The epics presented by the PO can be viewed as a placeholder each for a discussion.
:::

**The How**

* Stories can be broken down into smaller bits. This is where development details are discussed and additional PO questions asked.
* Ideally, each Task (which in our case are Clubhouse stories) shouldn't be longer than 1 working day.

## Outcomes

* Sprint Goal and what will be completed.
* How the work will be done (plan).
* Spring backlog.

# Daily Scrum

**Who attends:** Scrum Team and anyone interested (but only Scrum Team member provide updates)
**Duration:** Time-boxed for 15 minutes
**Time:** Every day at 9:15

The daily scrum is not a status meeting. It is actually a planning meeting.
Each developer team member answers the following 3 questions:
* What did I do yesterday to help meet the Sprint Goal?
* What will I do today to help meet the Sprint Goal?
* What impediments do I have that are blocking me (or the Development Team) from meeting the Sprint Goal?

At the end, the team inspects the **Burndown Chart** to be able to tell if the sprint is on-track.

:::info
After the time-boxed Scrum, Team members can continue detailed discussions to answer questions, solve problems, refine the design, or adapt the remaining Sprint work.
:::

# Backlog Refinement

**Who attends:** Scrum Team and anyone who has relevant input on shaping the Product Backlog
**Duration:** Time-boxed for 3 hours
**Time:** Once per Sprint, usually a little after the midpoint of the Sprint.

Backlog Refinement is not part of the diagram above. That is because it is not completely necessary for the entire Scrum Team to be part of this, albeit recommended. For experienced teams, select members are enough to provide input.

Backlog Refinement often takes up 5-10% of the Developer Team's time, and it's entirely worth it as it greatly reduces uncertainty and risk during planning. :wink:

## Goal
Provide the Product Owner with assistance in grooming the backlog, and making sure that the PO has all the information necessary to have the top of the Product Backlog ready for the next Sprint Planning.

## Topics
* Product Owner should present the prioritized Product Backlog and identifies what they would like to be part of the next Sprint.
* Development Team asks questions and requests additional details if needed

## Output
* Top of the Product Backlog ready for Sprint Planning.
* A list of PBIs for clarification and a list of questions to be answered.

## Definition of Ready

The "Definition of Ready" is a set of criteria agreed upon by the SCRUM team. Any story must meet these criteria before they can be planned into a sprint.

:::info
**Current Criteria:**
- States one or more real-life use-cases, making the value of the story clear.
- Done Criteria Aka. When this story is completed. This can just be when the use-case from above is possible, but it can contain more technical details as well.
- Are there any dependencies on other tasks?
:::

# Sprint Review

**Who attends:** The Scrum Team and any other Stakeholders who can offer feedback.
**Duration:** Time-boxed for 3 hours
**Time:** Usually last day of the Sprint, second-to-last event of the Sprint.

This event is centered around the result of the Sprint: the Product Increment. It is an informal meeting.

## Goal
Collaboratively inspect the Product Increment and if necessary adapt the Product Backlog.

## Topics
* Overview of the Sprint Goal and the selected PBIs. (Usually by the PO)
* Demonstration of the Product Increment by the Development Team.
* PO shares a status of the Product Backlog based on current progress.
* Open discussion between the Scrum Team and any Stakeholders, capturing feedback and any useful information for the Development Team.
* PO adds appropriate feedback into the Product Backlog.

# Sprint Retrospective

**Who attends:** The Scrum Team
**Duration:** Time-boxed for 2 hours
**Time:** Last event in the Sprint.

## Goal
Inspect and Adapt the Team's processes and select items for improvement.

## Topics
* Inspect how the last Sprint went in terms of People, Relationships, Collaboration, Processes, and Tools.
* Create an ordered list of things that went well, and things that didn't go well.
* Select 1-2 items for improvement and create a plan on how to address them.