---
# System prepended metadata

title: Working with scrum in Alkemio

---

# Working with scrum in Alkemio

![](https://i.imgur.com/GyxVZXE.png)


## 1. Responsibilities 

### 1.1 Scrummaster

*From the [scrum guide](https://stichtingcherrytwist.sharepoint.com/:b:/s/Contributors/EbbHVPESgR5KvjlyHIxXPIIBzhqJ0wV3H5qLOB70_jpyMQ?e=RKRJpv)*

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

The Scrum Master serves the Scrum Team in several ways, including:
- Coaching the team members in self-management and cross-functionality;
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
- Causing the removal of impediments to the Scrum Team’s progress; and,
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

The Scrum Master serves the Product Owner in several ways, including:

- Helping find techniques for effective Product Goal definition and Product Backlog management;
- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- Helping establish empirical product planning for a complex environment; and,
- Facilitating stakeholder collaboration as requested or needed.

### 1.2 Product Owner

*From the [scrum guide](https://stichtingcherrytwist.sharepoint.com/:b:/s/Contributors/EbbHVPESgR5KvjlyHIxXPIIBzhqJ0wV3H5qLOB70_jpyMQ?e=RKRJpv)*

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is also accountable for effective Product Backlog management, which includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.





## 2. The backlog

The backlog is an ordered list of what is needed to improve the product or organization. The operations backlog can be found [here](https://app.zenhub.com/workspaces/alkemio-operations-61fa389d8fd3600019f05c79/board?filterLogic=any&repos=454686072). 

### 2.1 Backlog items

We work with three levels of backlog items: initiatives, epics, issues (from big to small). They are explained below.

#### 2.1.1 Initiatives

*What is an initiative?*
An initiative is a collection of epics that drive toward a common goal. Initiatives can take multiple quarters. 


*Typical example of initiative?*
A project that we started for the Gemeente Den Haag that focuses on the participation of visually impaired people in the job market.

#### 2.1.2 Epics 

*What is an epic?*
Epics are large bodies of work that can be broken down into a number of smaller tasks (issues). It may take multiple sprints to complete an epic.

*Typical example of epic?*
Organising an event that takes place in five weeks time that should bring together all stakeholders for the visual impairement project.

#### 2.1.3 Issues

*What is an issue?*
An issue (also called user stories) are shor requirements or requests written from the perspective of an end user. During a sprint, many issues can be completed. 


*Typical example of issue?*
Sending out invites to all the participants for the visual impairement project.

### 2.2 Backlog stages

In order to structure all initiatives, epics and issues, they can be assigned to a certain stage. Below, the different stages are explained.

#### 2.2.1 Epic stages

*Epics - Icebox*
Epics are moved to the Icebox when they are not expected to be worked on during the coming sprints. It is the responsibity of the Product Owner to regularly check the Icebox. This could for example be once every month. 

*Epics - Parked*
When an Epic will not be worked out on the short term, it will be moved to 'Parked'

*New*
The 'New' column can be seen as the inbox for epics. When an epic is created, it can be placed in the New column.


*Not elaborated*
When an epic is assigned to someone + when this person understands to goal of the Epic, it moved to Not Elaborated. The assignee should elaborate the epic before the next sprint planning. During the sprint planning, all epics should be elaborated. This column should thus be empty by then. 

*Elaborated*
When an epic has been elaborated and broken down into issues, it can be moved to the Elaborated column. During the sprint planning, Epics will be moved from this column. There are three potential destinations: Icebox, Next sprints, Current sprint. After the sprint planning, this column will be empty.

*On-going commitments*
Some epics don't have a fixed end-date and will go on for a longer time. Think about the support of certain partners on the platform. These epics should be in the On-going commitments column. 

*In progress*
This column shows the epics that are being worked on during this sprint. They are moved here during the sprint planning, or during the sprint if necessary. 


*Closed*
Can be found on the far right of the board. It holds both epics and issues. An epics is moved here when it has been finished. 


#### 2.2.2 Issue stages


*Icebox*
Issues are moved to the Icebox when they are not expected to be worked on during the coming sprints. It is the responsibity of the Product Owner to regularly check the Icebox. This could for example be once every month.

*New issues*
When a new issue is created, it should be placed into the 'New issues' column. 

:question: When is it moved to product backlog?

*Product Backlog*

:question:  Should this one hold issues in the backlog that are **not** part of the sprint? Why would you have a backlog that hold many issues that is not part of this sprint?

*In progress*
This column hosts issues that are in progress.

*Review/QA*
When someone has to review a certain issue, it is placed in this column. Most of the times, this is when a team member will check the content (e.g. of a new blog post).

*Waiting for*
When an external party blocks the progress of an issue, it should be placed in this column.

*Blocked*
When an external party blocks the progress of an issue, it should be placed in this column.

:question: What is the difference between blocked and waiting for?
 
*Closed*
When an issue has been completed, is should be closed. This column also holds closed Epics.

### 2.2.3 Other

When an epic or issue unexpectedly needs a lot of attention in the short term, it is possible to prioritize it. It will be pinned to the top of the column. 






## 3. Sprint meetings 
Every sprint consists of two weeks (10 working days). Sprints start on tuesday and end on the monday 10 working days after the start. 

### 3.1 Daily standup

The goal of the Daily Standup is making sure everyone can execute their tasks without any problems. The standup should take 15 mins at most. It should not be necessary to discuss what everyone is going to do, but it might be good to know what every team member is up to (especially in a smaller team).

**Frequency -** 3 times a week
**When -** each monday, wednesday, friday
**Who -** operations team (Neil, Denise, Birgit, Mayte, Hoyte)
**Tasks -** scrummaster leads this meeting

### 3.2 Sprint planning
The goal of the sprint planning is determining what work should be done in the coming sprint. The planning looks as follows:

Planning 8 december: per epic van rechts naar links filteren en kijken welke issues erin ziten, die issues estimaten. Dan alle issues uit in progress, waiting for, QA naar nieuwe sprint verplaatsen. Dan vanuit de backlog issues selectren die we willen opnemen en in deze sprint zetten. Beoordelen of het aantal punten te veel / te weinig is. Make sure every issue has an assignee!

1. A sprint goal should be defined: what does this sprint focus on? 
3. Epics should be selected that correspond to this sprint goal. Epics that will be worked on this sprint will be placed into the right column in the backlog.
3. Issues move from new to backlog or to icebox
4. Size
5. Put into sprint 
6. How does the planning poker work? Sequence: determine epics to focus on, drag issues into backlog column, assign weight..?? 


**Frequency -** one per sprint
**When -** the day a new sprint starts (tuesday)
**Who -** operations team (Neil, Denise, Birgit, Mayte, Hoyte)
**Tasks -** product owner should make sure the entire team knows about the most important backlog items. All backlog items should be worked out before the sprint planning occurs. Scrummaster should remind everyone to elaborate / check the epics they are responsible for. 

### 3.3 Sprint review 

During the sprint review, the entire organization shows the accomplishments of the past sprint. Before the sprint review begins, each team should agree on who covers which topic/accomplishment. 

**Frequency -** one per sprint
**When -** the last day of a sprint (monday)
**Who -** entire organization 
**Tasks -** scrummaster coordinates during standup who will tell what during the daily standup that day. 

### 3.4 Sprint retrospective

During the sprint retrospective, there is time to reflect on the past sprint with regard to:

- individuals
- interactions
- processes
- tools
- definition of done

Questions to be answered are: what enabled you to work effectively and efficiently? What processes blocked you in achieving your goals? 

At the end, the most impactful improvements can be taken to the backlog. 

The retrospective is executed using [this Trello board](https://trello.com/b/vyqt7ll2/alkemio-ops-retrospectives).

**Frequency -** one per sprint
**When -** the first day of a sprint (tuesday)
**Who -** operations team (Neil, Denise, Birgit, Mayte, Hoyte)
**Tasks -** scrummaster makes sure everyone prepares this meeting

### 3.5 Refinements

Understanding what you should do, then break it down.
#### 3.5.1 Sales
During the sales refinement, we go through our [HubSpot Deals page](https://app-eu1.hubspot.com/contacts/25488729/objects/0-3), which is where we manage our leads. When we have a conversation with a lead, the notes are taken in Hubspot. The goal is to discuss the status on all existing leads and to update the team on new leads, to ensure everyone is up to speed of the conversations that are being held. 

**Frequency -** once per sprint
**When -** first thursday of sprint
**Who -** Neil, Hoyte, Merijn

#### 3.5.2 Usage
During the usage refinement, we're taking a look at our ongoing commitments with regards to our platform users. All of these should be in the 'Ongoing commitments' column on Zenhub. 

**Frequency -** once per sprint
**When -** second thursday of sprint
**Who -** Neil, Hoyte, Denise, Mayte


### 3.6 Timeline

![](https://i.imgur.com/69cPEH5.png)



:::spoiler
[The sheet can be found / adapted here](https://stichtingcherrytwist.sharepoint.com/:x:/s/Contributors/EZ7JkJT9Ir9Di2QB3UP_vqYBzpSSBwRRu-jdP2jWOy1d7w?e=7GIH0O)
:::

## 4. Questions 

- Why not assign epics to sprints?
Issue sizing decide what you can do. Maybe try?
- Why not get rid of the being elaborated, etc. Just use a label to mark them when they're not elaborated. Then we can use epic columns to assign them to this sprint or the next one?

Agreement: Each Epic is assigned to individual.





- Suggestion: retro once every four weeks? 
- Collective refinement of the board: when does it happen? 

**Suggestion by Hoyte re Epics**

Icebox, On-going commitments, New, Next sprint, This sprint

A few agreements should be made:
1. When a new epic enters the board, it should go into the new column. When not refined, it gets a label "not refined". Each epic should have an assignee.
2. When the sprint planning starts, no single epic may be "not refined". Assignees are responsible.
3. After the sprint planning, no single epic may be in new anymore. 
4. The "next sprint" column may only contain a limited amount of epics (e.g. 6). Otherwise it is too easy to place everything in the "next sprint".
5. From time to time, the Icebox should be checked thoroughly. I think this is the Product Owner role? How often? Before each sprint planning? 