Scrum Process

TODO

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

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 over lock-in
Self- over Top-down organization
Transparency over opacity
Self-service over Support
Help over blame

Source of Truth

The Jira Board 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:

Jira ticket has same title as the GitHub issue
Jira ticket description links to the upstream issue (i.e. it is sufficient to drop a link there)
Status and comments should be maintained on the upstream issue
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 in Jira. When working on bugs:

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

Current Sprint Board is up-to-date
New sprint created (but not started) and loaded up with: feature work + possible bug work - tickets should be in priority order.
Estimated capacity for coming sprint updated
Actual capacity for previous sprint updated
Moving average of bugs in
Moving average of velocity
A ticket has been created to communicate features or bugs landing in next openshift.Next release

Agenda

Close current sprint, move unfinished BLIs to next sprint, and update velocity
Update BugDocCop schedule and update calendar.
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)
5. Once we agree and commit to the backlog, start the sprint
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
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

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

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
BLIs should meet the DoR - 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 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 (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 (20 minutes)
Assign owners to the action items 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 - but does not need to be sized

Tech Debt Identified During Development

Create upstream and/or Jira issue meeting the standard of the DoR
Add a link to the issue in a comment around the target code with a short explanation
Add Jira issue to the tech debt epic

Misc. Tech Debt

Create upstream and/or Jira issue meeting the standard of the DoR
Add Jira issue to the tech debt epic

Prior to the team refinement team votes on most pressing items
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

grokspawn

2022/05/10 15:02:54

Discuss any sit-down topics

Do we need to 'protect the team' by noting that only the team gets to talk during standup (i.e. PM, mgmt, other invitees don't affect the team's day plan, but can contribute things after/sitdown-time)? (Edited)

2022/05/10 15:04:05

What's the resolution plan for issues that require add'l tech discussion? Worth it to say that we'll spin off other meetings to support that need, and reconvene refining in a later refining session? (Edited)

Tyler Slaton

2022/05/10 15:14:24

As if it is its own separate entity

Should also make sure we're allocating the proper time to manage these upstream entities? Tending to our upstream communities might become tricky if we don't give ourselves enough breathing room to do it. (Note: I feel we already do this well but want to make sure we keep doing it) (Edited)

Alexander Greene

2022/05/10 15:23:31

who will be BDC this sprint

I've had difficulty keep track of who is assigned BDC lately, is it time to reevaluate the BDC role? At the very least it would make sense to get an update from BDC if we're still going to use the role. (Edited)

2022/05/10 15:24:38

It seems like our new question queue system has allowed people outside of BDC to address questions as they come, it would be good to update BDC to account for this new system. (Edited)

Per Goncalves da Silva

2022/05/10 15:45:49

### What about bugs? Bugzilla bzs are [mirrored](https://issues.r

Action Item: spike to see if we can automate ticket movement through the board by linking PRs (Edited)

Nick Hale

2022/05/19 14:38:11

- PR should include, when necessary:

At what scope? i.e. Is it useful to describe the input/ouput for every unit test, or do we want to stick to describing high-level functional tests? e.g. a BundleInstance surfaces status condition X when it fails to apply a Bundle to the cluster; Status condition X is cleared when the application is successful; etc. (Edited)

2022/06/03 21:47:33

Take team temperature (i.e. average happiness 0 - I'm done with this place to 10 - I'm never leaving this place)

What do we do with this metric? e.g. review the rate of change over the past N sprints. Is there something actionable? (Edited)

2022/05/10 14:59:15

Can we change to "prefer to keep this out of stand-up for brevity" or similar? (Edited)

Daniel Sover

2022/05/10 15:09:26

the issue should be cloned in Jira:

Who is responsible for cloning upstream issues into our JIRA board? (Edited)

2022/05/10 15:10:39

Does this imply that there are more meetings that are just shorter? Might be good to set a tenet for the frequency of meetings. (Edited)

Vu Dinh

2022/05/10 15:19:05

This is a bit oversimplified. The term phrase "targeted audience over add-them-all". (Edited)

2022/05/10 15:25:59

It would be great to review the goals of each meeting at the start until it's ingrained in us. (Edited)

2022/05/10 15:26:34

working on bugs

How do we handle bugs that come in via slack or upstream channels? (Edited)

2022/05/10 15:31:09

Action Item: codify upstream governance (Edited)

2022/05/10 15:31:30

Everyone should feel empowered to add BLIs (Edited)

2022/05/10 15:31:44

It's "our" board in the communist sense (Edited)

2022/05/10 15:32:00

Action Item: We should automate this effort (Edited)

2022/05/10 15:35:08

Action Item: Spike on Automation (Edited)

2022/05/10 15:49:11

Action Item: Update all meeting meeting request descriptions to include goals, agenda, etc. (Edited)

2022/05/10 15:50:06

Action Item: Have meeting to review whether we still need this and what it is (Edited)

2022/05/10 15:56:38

e.com/document/d/1

Action Item: Meeting to agree on DoD, DoR, DoG (Edited)

2022/05/10 15:59:59

Action Item: Also create Jira Epic and issue templates (Derwin to lead) (Edited)

oceanc80

2022/05/19 13:59:36

PR description must contain

Could we set up description templates in github for anything we require? (Edited)

2022/05/19 14:39:35

(in part, making the latter easily grokable is what Ginkgo aims to solve with its DSL) (Edited)

2022/05/19 14:39:58

cc @FGB_im5qRNSh-ert2qWibw (Edited)

2022/05/31 07:45:46

Testing remarks (optional):

@njhale is this better? (Edited)

2022/06/01 17:38:24

reviewer

Didn't know that I had edit permissions.... fixed! (Edited)

2023/01/23 16:16:02

pdate [BugDocCop](https://docs.google.com/spreadsheets/d/1zxuKmsYEbppMXj-jN5ggd7Vmr99RJSQ3bxpLs37906Q/edit#gid=1896529908) schedule and update calendar.

@6iuV5PyMRKqdQ96lfHCaiA Update this process. (Edited)

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`	在筆記中貼入程式碼
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.

Scrum Process

TODO

Terms and Definitions

Definition of Done (Until we find a better one)

Definition of Ready (Until we find a better one)

Team Charter

Process Goals - Until we find better ones

Team Process Tenets - Until we find better ones

Source of Truth

What about upstream issues?

What about bugs?

Meetings

Planning Meeting

Goals

Key Metrics

Prerequisites

Agenda

Stand Up

Prerequisites

Goals

Agenda

Rules

Team Refinement

Prerequisites

Goals

Non-Goals

Agenda

Epic Refinement

Prerequisites

Goal

Suggested Agenda

Demo/Review

Goal

Prerequisites

Agenda

Retrospective

Goals

Prerequisites

Agenda

Technical Debt

Responsibility

Definition of Tech Debt:

Tech Debt Identified During Development

Misc. Tech Debt

Refinement

PR Reviews