---
tags: development process, team
---
# Scrum Process

## TODO

- [x] Have team culture meeting
- [x] Review Scrum process
- [x] Update meeting descriptions
- [x] Ideate DoD and DoR
- [ ] Agree on DoD and DoR
- [ ] Define BDC/On-call
- [ ] Finish and sign [charter](https://miro.com/app/board/uXjVO5gMMi4=/)

## Terms and Definitions

* BLI - Backlog Item (story, task, spike, etc.)
* DoD - Definition of Done
* DoR - Definition of Ready (to execute)

### Definition of Done (Until we find a better one)

- Reviewed
- Tested - inc. unit/e2e/etc.
- Meets Acceptance Criteria
- Documented (if necessary)
- Demo created (if necessary)
- Follow-up work is captured in Jira (if necessary)
- Merged
- Sync'ed Downstream (if necessary)

### Definition of Ready (Until we find a better one)

- As small as possible/tightly scoped
- Stakeholders and dependencies identified
- Dependencies are met
- Description includes context: whom? what? why? when? (but not how?)
- Has acceptance criteria
- Sized by complexity (1, 2, 3, 5, 8, 13)

## Team Charter

The team charter can be found [here](https://miro.com/app/board/uXjVO5gMMi4=/)

## Process Goals - Until we find better ones

Any process we settle on should meet the following criteria:
- Not owned by any single individual/role - it is for the team, by the team and of the team
- Iterative and lends itself to continuous improvement
- Transparent and documented
- Prioritizes quick decision making over bike-shedding
- Lean - each ceremony should only involved the people needed and no more
- Facilitates work rather than stifles it
- Respects/Integrates Org. processes
- Everyone has something to do, no one has too much
- Respects working hours and team capacity

## Team Process Tenets - Until we find better ones

- Synchronous over Asynchronous feedback
- Documented decisions over Tribal Knowledge
- Target audience over everyone (for meetings)
- [Two-way door decisions](https://shit.management/one-way-and-two-way-door-decisions/) over lock-in
- Self- over Top-down organization
- Transparency over opacity
- Self-service over Support
- Help over blame

## Source of Truth

The [Jira Board](https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=5362) is our source of truth. Whatever the team is working on during the sprint is tracked on the board.

### What about upstream issues?

Upstream projects have their own governance and release cadence. We should treat the upstream as if we don't own it. As if it is its own separate entity with its own processes and governance. If we need to pull in work that has been modeled upstream in GitHub, the issue should be cloned in Jira:
1. Jira ticket has same title as the GitHub issue
2. Jira ticket description links to the upstream issue (i.e. it is sufficient to drop a link there)
3. Status and comments should be maintained on the upstream issue
4. Status (In Progress, Review, etc.) should be maintained both up- and downstream (boards should be up-to-date before stand-up)

### What about bugs?

Bugzilla bzs are [mirrored](https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=5586&projectKey=OLM&view=planning.nodetail&issueLimit=100) in Jira. When working on bugs:
1. Pull in the cloned Jira ticket into the sprint (at

or during the sprint)
2. Maintain all conversation and status on the bugzilla ticket (the sync will keep the board up-to-date)

## Meetings

### Planning Meeting

**Duration**: 1 hours
**Frequency**: 1 / sprint
**Who**: Dev team + PM (opt) + Manager (opt) + Stakeholders (opt)

#### Goals
- Review our key metrics
- Commit to work we can deliver in the sprint
- Under promise/Over deliver - better to be conservative and add fewer points (and pull in additional work from the backlog if necessary) than to tackle the world and only deliver half of it
- Everyone leaves understanding:
- what value are we delivering this sprint to our customers
- what will we do to improve our productivity (i.e. docs, automation, tech debt)
- what we need to do to keep below our bug SLO
- who will be BDC this sprint

#### Key Metrics
- Moving average of bugs in for the past 5 sprints
- Moving average of velocity for the past 5 sprints

#### Prerequisites

1. Current Sprint Board is up-to-date
2. New sprint created (but not started) and loaded up with: feature work + possible bug work - tickets should be in priority order.

4. [Estimated capacity](https://docs.google.com/spreadsheets/d/17gZ8y-0S8s_MYpSgD9Ok07h4L5wrXJu54C_F5jBncr8/edit#gid=0) for coming sprint updated
5. Actual capacity for previous sprint updated
6. Moving average of bugs in
7. Moving average of velocity
8. A ticket has been created to communicate features or bugs landing in next openshift.Next release

#### Agenda

1. Close current sprint, move unfinished BLIs to next sprint, and update velocity
2. Update [BugDocCop](https://docs.google.com/spreadsheets/d/1zxuKmsYEbppMXj-jN5ggd7Vmr99RJSQ3bxpLs37906Q/edit#gid=1896529908) schedule and update calendar.
3. Split into sub-team break out rooms; and per team
1. Estimate number of points we can bring in (cap x velocity)
2. Pull in as many BLIs as our scaled velocity will allow
3. Shed points, if necessary, in response to the bug load
4. Sprint name should contain the OCP sprint number for 4.Next tracking purposes, examples:
>Darth 224 (pass)
>224 Luke (pass)
>Wild 224 Crazy (pass)
>Boba224 (fail)
>224Mando (fail)
6. Once we agree and commit to the backlog, start the sprint
4. Join in the main meeting

### Stand Up

**Duration**: 0.5 hours
**Frequency**: Everyday except first and last day of sprint
**Who**: Dev team + PM (opt) + Manager (opt) + stakeholders (opt)

#### Prerequisites
- If any external people should join, ensure they have been invited and have the meeting request

#### Goals
- Ensure our high priority goals are on track
- Ensure no one is blocked or needs help
- Update the sprint plan if necessary (e.g. new urgent bug comes in)
- Ensure board is up-to-date
- Review support requests and assign them out if necessary
- Review BugDocCop status
- Discuss sit down topics, if any: announcements, general questions, etc.

#### Agenda
- Get the status of each epic in priority order
- Get status of high/urgent bugs
- Get status for co-ops
- Get status from BugDocCop
- Review [Slack support requests](https://docs.google.com/spreadsheets/d/1f5Gc0C8ITyLDgXEDhHyg5i5XBKALmsAqSThuB5wsaRQ)
- Discuss any sit-down topics

#### Rules
- Managers (and others - not the devs) should not push their own agendas here, this meeting is for the team to sync. on the sprint goals - but can contribute to sit-down topics

### Team Refinement

**Duration**: 1 hour
**Frequency**: 2 / sprint
**Who**: Dev team + PM (when necessary) + Manager (opt)

#### Prerequisites
- Refinement Backlog is populated and in priority order

#### Goals
- Ensure refined BLIs are ready to be worked on and are understood
- Size BLIs

#### Non-Goals
- Deep technical discussion

#### Agenda
- Epic lead describes the ticket and its goals
- Team asks questions and decides whether the ticket is defined well enough to execute
- We time box each item to **5 minutes**. If we decide a ticket isn't ready for sizing, go to the next. Repeat until all tickets have been examined. Time box the remaining time to list out what is missing from BLIs that are not ready yet
- Epics leads should collect the feedback and together with the epic team address the issues identified and re-present the tickets at a future refinement meeting

### Epic Refinement

**Duration**: 0.5-1 hour (suggested) - can be extended if the epic calls for it
**Frequency**: 2 / sprint
**Who**: Epic Owner + Team Lead + Manager (opt) + Staff Eng. (opt) + Stakeholders (opt) + Subject Matter Experts (opt)

#### Prerequisites
- BLIs don't need to already exist. This meeting can be used for ideation to create the runway
- Though, Epic owner should at least have a clear idea of what the current status is and what the likely next steps would be

#### Goal
- Look ahead in the Epic and populate the refinement backlog with BLIs that are ready to be understood, broken down, and sized by the team in the [Team Refinement](#Team-Refinement)
- BLIs should meet the [DoR](#Definition-of-Done-Until-we-find-a-better-one) - except for sizing. This will be done in the team refinement.

#### Suggested Agenda

The agenda can change from epic to epic. This should be a more/less open meeting where we can go deeper in the technical discussion and agree on the right path forward. Therefore, it's important to only include people that need to be there.

The suggested agenda would be:
- 25% discussing status and the next steps
- 75% crafting tickets

### Demo/Review

**Duration**: 1 hour
**Fequency**: 1 / sprint
**Who**: Dev team + PM (opt) + Manager (opt) + Stakeholders (opt)

#### Goal
- Showcase the hotness we produced in the sprint
- Collect feedback from stakeholders

#### Prerequisites
- Demos registered [here](https://docs.google.com/document/d/1DiizfqNc7t2w8o8BagJLW5h-9ldRH31yTKQ21TK2chA/edit) with estimated duration - include at least 5-10 minutes for discussion
- Epic Stakeholders invited

#### Agenda
- Review demos and make sure we have enough time for everything
- In epic priority order, demo the hotness within the time period
- Answer questions and collect feedback
- Add more tickets to the backlog if necessary

### Retrospective

**Duration**: 1 hour
**Frequency**: 1 / sprint
**Who**: Dev team

#### Goals
- Reflect on the sprint
- Come up with a set of action items that improve our processes and/or well-being

#### Prerequisites
- Retro is a safe space anything can and should be discussed (respectfully)
- If you can, get in the habit of writing things down to bring up during the sprint

#### Agenda

- Go over last retro's [action items](https://docs.google.com/document/d/1nLpPFf9rn6cq4QwboHEv2w7c-KbQQhfAA4SagJrKp-M) (5 minutes)
- Take some time to reflect on the sprint. (10 minutes)
-- Create cards and place them in the "What went well" and "What should we improve" collumns on the Miro Board.
-- As you add the cards, try to cluster cards into groups that share the same sentiment.
- Speak to each "cluster" of cards (15 minutes)
- Showrunner adds a "VOTE" card to each cluster of cards (1 minute)
- Silent voting on issues to discuss (5 minutes)
- Discuss issues in order and take down [action items](https://docs.google.com/document/d/1nLpPFf9rn6cq4QwboHEv2w7c-KbQQhfAA4SagJrKp-M) (20 minutes)
- Assign owners to the [action items](https://docs.google.com/document/d/1nLpPFf9rn6cq4QwboHEv2w7c-KbQQhfAA4SagJrKp-M) and close (5 minutes)
- Take team temperature (i.e. average happiness 0 - I'm done with this place to 10 - I'm never leaving this place)

## Technical Debt

### Responsibility

It is the team's responsibility to document, track and advocate for tech debt

### Definition of Tech Debt:
- Any work that will improve the product that we couldn't get to
- Any work that can improve our process or quality of life, e.g. automation
- Tech debt BLIs meet the standards set by the [DoR](#Definition-of-Done-Until-we-find-a-better-one) - but does not need to be sized

### Tech Debt Identified During Development
1. Create upstream and/or Jira issue meeting the standard of the [DoR](#Definition-of-Done-Until-we-find-a-better-one)
2. Add a link to the issue in a comment around the target code with a short explanation
3. Add Jira issue to the [tech debt epic](https://issues.redhat.com/browse/OLM-2323)

### Misc. Tech Debt
1. Create upstream and/or Jira issue meeting the standard of the [DoR](#Definition-of-Done-Until-we-find-a-better-one)
2. Add Jira issue to the [tech debt epic](https://issues.redhat.com/browse/OLM-2323)

### Refinement
1. Prior to the team refinement team votes on most pressing items
2. Pull in the, e.g., top 3 voted items into refinement and refine

## PR Reviews

**Goal**: To uphold high code quality and engineering standards in the project, to keep contributions within the rails of the project goals, vision and guidelines, and to avoid adding technical debt. All while providing the best possible experience to keep contributors comming back.

**Culture**: In business, the saying goes, we should try to make a customer and not a sale. In open-source we should try to make a contributor and not a PR merge. Every reviewer should be a partner to the contributor. The PR review process should not just be seen as a bureaucratic quality gate process. It should be collaborative. The outcome of a review should not be "this does/doesn't meet the standard", but rather, "this is what _we_ need to do to meet the standard". Getting one's work criticised can be a daunting experience. We should always aim to be truthful, helpful, and whenever possible, kind - and always keep in mind that tone and intention aren't so easy to convey in written form.

**Standard**:

- PR description must contain:
- Detailed Description of change
- Reason for change
- Description of any architectural changes (when necessary):
- Briefly describe any architectural changes, other options considered, and/or link to any EPs or design docs
- Testing remarks (optional):
- Call out any information around how you've tested the code change that may be useful for reviewers. For instance:
* any edge-cases you have (dis)covered
* how you have tested for regressions in bug fixes
* how you've tested for flakes in e2e tests or flake fixes
- PR should include, when necessary:
- Sufficient testing: unit/e2e/regression
- Documentation: end-user/architectural changes
- Link to progenitor EP
- Reasonable/Pragmatic Tech Debt should be documented in code with a link to an upstream issue that describes the debt, why it is there, and what is needed to address it
- PR reviews and comments should be:
- Respectful
- Helpful
- Kind, if possible
- If possible, call out what is good, as well as what needs improvement
- Within reason, comments for improvement should include a suggestion for how it should be improved as well as why it should be improved
- The reviewer should rely on subject matter experts if not sufficiently aware of the code areas being touched by a PR

**Resources**

* [Google Review Developer Guide](https://google.github.io/eng-practices/review/)