From 6c7f20b6b05a7a8f1681024da1f5a2ebc1d4f4e4 Mon Sep 17 00:00:00 2001 From: Jackson Hoffart Date: Wed, 25 Mar 2026 12:56:21 +0100 Subject: [PATCH 1/7] docs(process): add OKR and agile practice guides --- process/agile/ceremonies.md | 103 ++++++++++++++++++++++++++++++++++++ process/agile/jira.md | 90 +++++++++++++++++++++++++++++++ process/agile/overview.md | 87 ++++++++++++++++++++++++++++++ process/okrs.md | 74 ++++++++++++++++++++++++++ 4 files changed, 354 insertions(+) create mode 100644 process/agile/ceremonies.md create mode 100644 process/agile/jira.md create mode 100644 process/agile/overview.md create mode 100644 process/okrs.md diff --git a/process/agile/ceremonies.md b/process/agile/ceremonies.md new file mode 100644 index 0000000..75a49a3 --- /dev/null +++ b/process/agile/ceremonies.md @@ -0,0 +1,103 @@ +# Agile Ceremonies + +This document defines the sprint cadence. Teams may adapt the exact format, but the core outputs should stay consistent. + +## Suggested Cadence + +| Ceremony | Frequency | Duration | Primary Output | +| --- | --- | --- | --- | +| Sprint Planning | Every sprint | 1.5 to 2 hours | Sprint goal and committed work | +| Daily Scrum | Daily | 10 to 15 minutes | Shared plan and visible blockers | +| Backlog Refinement | Weekly | 30 to 60 minutes | Ready backlog | +| Sprint Review | End of sprint | 1 to 2 hours | Feedback and accepted work | +| Retrospective | End of sprint | 30 to 60 minutes | One or two improvements | + +Two-week sprints are a good default, but teams may adapt based on project size and learning speed. + +## Sprint Planning + +Purpose: + +- set a clear sprint goal +- choose a realistic amount of work +- confirm a shared understanding of scope and acceptance criteria + +Inputs: + +- current PRD or delivery plan +- prioritized backlog +- team capacity +- known risks and dependencies + +Outputs: + +- sprint goal +- committed work +- initial task breakdown as needed + +## Daily Scrum + +Purpose: + +- synchronize the team +- surface blockers quickly +- adjust the plan before drift grows + +This can be synchronous or async. For distributed teams, async is often better. + +Suggested async format: + +- Yesterday: what changed +- Today: next planned work +- Blockers: what needs help + +The Scrum Lead should review blockers daily and actively remove them. + +## Backlog Refinement + +Purpose: + +- keep the top of the backlog ready +- clarify scope before planning +- split large work into smaller slices + +Use refinement to: + +- translate feedback into backlog items +- add or improve acceptance criteria +- identify dependencies and technical constraints +- do first-pass estimation if useful + +## Sprint Review + +Purpose: + +- demonstrate completed increments +- gather stakeholder feedback +- decide what changes next + +Outputs: + +- accepted or rejected work +- feedback captured as new or updated tickets +- follow-up actions with owners + +## Retrospective + +Purpose: + +- inspect how the sprint worked +- identify one or two changes to improve the next sprint + +Keep retrospectives short, honest, and blameless. If every retro produces a long list, the team will ignore it. + +## Estimation And Capacity + +- use relative estimation when it helps compare effort +- re-estimate only when scope materially changes +- subtract meetings, support work, holidays, and buffer before committing +- track carryover and use it to improve planning, not to blame + +## Practical Rule + +Each ceremony should produce a decision or artifact the team actually uses. If a meeting exists only because the calendar says it should, simplify it or remove it. diff --git a/process/agile/jira.md b/process/agile/jira.md new file mode 100644 index 0000000..f0b4510 --- /dev/null +++ b/process/agile/jira.md @@ -0,0 +1,90 @@ +# Jira Runbook + +This document explains how to implement the agile operating model in Jira. The goal is not perfect Jira hygiene. The goal is clear, visible delivery. + +## tl;dr + +- use Jira to make priorities, ownership, and status visible +- keep workflows simple +- make tickets ready before sprint planning +- keep sprint goals explicit +- capture feedback as backlog items, not scattered notes + +## Recommended Structure + +Suggested issue hierarchy: + +- Epic: a meaningful body of work tied to a PRD, milestone, or outcome +- Story: a sprint-sized unit of work +- Bug: a defect that needs triage and delivery + +## Recommended Workflow + +Suggested statuses: + +- Backlog: captured work that is not yet ready or prioritized for an upcoming sprint +- Selected for Development: prioritized work with enough context and acceptance criteria to bring into planning +- In Progress: work actively being implemented +- In Review: work believed to meet acceptance criteria and awaiting review, demo, or approval +- Done: reviewed work that has been accepted and does not need more delivery work in the current cycle + +## Sprint Setup + +Before starting a sprint: + +- confirm the backlog is prioritized +- make sure selected tickets have acceptance criteria +- account for time off, support load, and known dependencies +- draft the sprint goal before the planning meeting + +At sprint start: + +- create the sprint +- add the committed issues +- set the sprint goal in Jira + +## Writing Good Jira Tickets + +Each ticket should include: + +- a concise outcome-focused title +- user or business context +- acceptance criteria +- story point estimates +- relevant links to PRDs, designs, or technical notes +- clear ownership when work begins + +Good tickets reduce clarification churn during the sprint. + +## Acceptance Criteria + +Acceptance criteria should describe what proves the work is done. + +Good acceptance criteria are: + +- specific +- testable +- understandable by both product and engineering + +Avoid acceptance criteria that are only implementation notes. + +## Board Hygiene + +- do not pull work into a sprint unless it is ready +- keep ticket status current +- split oversized tickets instead of carrying ambiguity forward +- capture review feedback in Jira when it changes scope or priority +- close the sprint with clear decisions on incomplete work + +## Sprint Review In Jira + +After review: + +- move accepted work to Done +- move incomplete work to the correct active state +- create follow-up tickets from stakeholder feedback +- update priorities before the next planning cycle + +## Atlassian Goals Note + +If your team uses Atlassian Goals for OKRs, use it as the outcome layer above Jira delivery work. Goals should describe the intended result; Jira issues and sprints should show the work advancing that result. Keep the linkage visible, but do not replace good OKRs with a long list of Jira tickets. diff --git a/process/agile/overview.md b/process/agile/overview.md new file mode 100644 index 0000000..e082a43 --- /dev/null +++ b/process/agile/overview.md @@ -0,0 +1,87 @@ +# Agile Overview + +Agile is a way to deliver better products through small increments, fast feedback, and clear ownership. These concepts work regardless of if a team is using post-it notes, GitHub issues, Linear or Jira. + +## tl;dr + +- optimize for outcomes, not outputs +- work in small, testable increments +- keep the backlog ready and prioritized +- use sprint goals to focus the team +- inspect and adapt every sprint + +## Why This Leads to Better Products + +Strong agile practice reduces delivery risk by shortening feedback loops. It helps teams learn earlier, change direction faster, and avoid spending weeks building the wrong thing. + +## Operating Principles + +- Outcome driven: deliver work that advances product goals. +- Small batches: prefer slices that can be built, reviewed, and learned from quickly. +- Fast feedback: get stakeholder and user input early and often. +- Shared ownership: product, engineering, and delivery leads all shape success. +- Continuous improvement: carry a small number of lessons from one sprint into the next. + +## Roles + +- Product Manager / Product Owner: owns product outcomes, backlog priority, and PRD alignment. +- Tech Lead: shapes technical approach, feasibility, and sequencing. +- Scrum Lead: facilitates cadence, surfaces blockers, and protects healthy flow. +- Engineering Team: estimates, commits, builds, tests, and demos. +- Stakeholders / SMEs: provide feedback and domain context. + +These roles are not always separate people. + +## Delivery Flow + +Recommended states: + +- Backlog +- Selected for Development +- In Progress +- In Review +- Done + +The important rule is not the exact labels. The important rule is that work should move through a small, visible set of states with clear entry criteria. + +## Link To Strategy + +Use this chain: + +`OKRs -> PRDs -> epics/stories -> sprint goals` + +See [OKRs](/Users/jhoffart/github/practices/process/okrs.md) for guidance on defining outcomes. + +## Good Sprint Goals + +A strong sprint goal: + +- is one or two sentences +- describes the outcome of the sprint +- connects to a PRD, milestone, or key result +- helps the team make tradeoffs during the sprint + +Anti-pattern: Weak sprint goals are just a list of tickets. + +## Good Tickets + +A ticket is ready when it has: + +- clear user or business value +- enough context to start +- acceptance criteria +- known dependencies, blockers or constraints +- a size that fits inside a single sprint + +If the ticket is too large to reason about, split it before bringing it into the sprint. + +## Working Agreements + +- prefer small PRs and review them within 24 business hours +- document decisions in shared channels +- keep acceptance criteria current when scope changes +- account for capacity, support load, and time off before committing work + +## Practical Rule + +If the team cannot explain why a ticket matters, what done looks like, and how it supports a larger product goal, it is not ready. diff --git a/process/okrs.md b/process/okrs.md new file mode 100644 index 0000000..9597276 --- /dev/null +++ b/process/okrs.md @@ -0,0 +1,74 @@ +# OKRs + +Objectives and Key Results (OKRs) help teams define the outcomes they want to create and how they will measure progress. They should create focus, not overhead. + +## tl;dr + +- Objectives describe the change you want to create. +- Key Results define how you will know it happened. +- OKRs should guide prioritization, PRDs, and sprint goals. +- OKRs are not a task list. + +## What Good Looks Like + +A strong objective is: + +- outcome-oriented +- easy to understand +- important enough to shape priorities + +A strong key result is: + +- measurable +- time-bounded +- meaningful to users or the business +- hard enough to require real tradeoffs + +## What OKRs Are Not + +Avoid OKRs that are: + +- just a list of deliverables +- too vague to measure +- too broad to guide decision-making +- disconnected from actual product work + +## How OKRs Connect to Delivery + +Use this chain: + +`OKRs -> PRDs -> epics/stories -> sprint goals` + +That means: + +- OKRs define the outcome +- PRDs define the product approach +- backlog items define the work +- sprint goals define the near-term delivery focus + +## Writing Guidance + +Use objectives to state the desired change. + +Example: + +- Improve the onboarding experience so new users reach value faster. + +Use key results to define measurable evidence. + +Examples: + +- Increase activation rate from 42% to 60%. +- Reduce median time-to-first-value from 5 days to 2 days. +- Raise onboarding CSAT from 3.8 to 4.3. + +## Common Failure Modes + +- writing key results that are really tasks +- setting too many OKRs at once +- measuring activity instead of impact +- never using OKRs to make prioritization decisions + +## Practical Rule + +If a team can complete every planned task and still miss the intended outcome, the OKR is not yet sharp enough. From 5f29abd985a40c4d1b5e255fd95992e304ce2d9b Mon Sep 17 00:00:00 2001 From: Jackson Hoffart Date: Wed, 25 Mar 2026 12:56:35 +0100 Subject: [PATCH 2/7] docs(readme): add OKR and agile docs to ToC --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index df2e922..70d9039 100644 --- a/README.md +++ b/README.md @@ -20,6 +20,10 @@ This guidance is for all contributors. Repository maintainers are accountable fo - [Git](process/git.md) - [Pull Requests](process/pull_request.md) - [Software Versioning](process/version.md) +- [OKRs](process/okrs.md) +- [Agile Overview](process/agile/overview.md) +- [Agile Ceremonies](process/agile/ceremonies.md) +- [Jira Runbook](process/agile/jira.md) ### Architecture - API design principles (planned) From 651dd734506f8fb3de0ace9a04b59bac03cadb00 Mon Sep 17 00:00:00 2001 From: Jackson Hoffart Date: Wed, 25 Mar 2026 13:35:50 +0100 Subject: [PATCH 3/7] Update process/agile/overview.md Co-authored-by: Alex Axthelm --- process/agile/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/agile/overview.md b/process/agile/overview.md index e082a43..8128f9d 100644 --- a/process/agile/overview.md +++ b/process/agile/overview.md @@ -30,7 +30,7 @@ Strong agile practice reduces delivery risk by shortening feedback loops. It hel - Engineering Team: estimates, commits, builds, tests, and demos. - Stakeholders / SMEs: provide feedback and domain context. -These roles are not always separate people. +These roles are not always separate people, but it is important that the PM/PO is distinct from the development/engineering team, so that the project stays focused on product outcomes, rather than technical ones ## Delivery Flow From 47fe35a73782d9f398603fee7f0c60ec328a48b8 Mon Sep 17 00:00:00 2001 From: Jackson Hoffart Date: Wed, 25 Mar 2026 13:37:45 +0100 Subject: [PATCH 4/7] add participants to ceremonies table --- process/agile/ceremonies.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/process/agile/ceremonies.md b/process/agile/ceremonies.md index 75a49a3..f18058d 100644 --- a/process/agile/ceremonies.md +++ b/process/agile/ceremonies.md @@ -4,13 +4,13 @@ This document defines the sprint cadence. Teams may adapt the exact format, but ## Suggested Cadence -| Ceremony | Frequency | Duration | Primary Output | -| --- | --- | --- | --- | -| Sprint Planning | Every sprint | 1.5 to 2 hours | Sprint goal and committed work | -| Daily Scrum | Daily | 10 to 15 minutes | Shared plan and visible blockers | -| Backlog Refinement | Weekly | 30 to 60 minutes | Ready backlog | -| Sprint Review | End of sprint | 1 to 2 hours | Feedback and accepted work | -| Retrospective | End of sprint | 30 to 60 minutes | One or two improvements | +| Ceremony | Frequency | Duration | Participants | Primary Output | +| --- | --- | --- | --- | --- | +| Sprint Planning | Every sprint | 1.5 to 2 hours | Core team, product owner | Sprint goal and committed work | +| Daily Scrum | Daily | 10 to 15 minutes | Core team | Shared plan and visible blockers | +| Backlog Refinement | Weekly | 30 to 60 minutes | Product owner, Core team, subject matter experts as needed | Ready backlog | +| Sprint Review | End of sprint | 1 to 2 hours | Core team, product owner, stakeholders | Feedback and accepted work | +| Retrospective | End of sprint | 30 to 60 minutes | Core team | One or two improvements | Two-week sprints are a good default, but teams may adapt based on project size and learning speed. From 13df7ce356d2688e6814832534959e84410536d0 Mon Sep 17 00:00:00 2001 From: Jackson Hoffart Date: Thu, 26 Mar 2026 10:27:26 +0100 Subject: [PATCH 5/7] Apply john's suggestions from review Co-authored-by: Jackson Hoffart --- process/agile/overview.md | 4 ++-- process/okrs.md | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/process/agile/overview.md b/process/agile/overview.md index 8128f9d..b60b81e 100644 --- a/process/agile/overview.md +++ b/process/agile/overview.md @@ -30,7 +30,7 @@ Strong agile practice reduces delivery risk by shortening feedback loops. It hel - Engineering Team: estimates, commits, builds, tests, and demos. - Stakeholders / SMEs: provide feedback and domain context. -These roles are not always separate people, but it is important that the PM/PO is distinct from the development/engineering team, so that the project stays focused on product outcomes, rather than technical ones +These roles are not always separate people, but it is important that the PM/PO is distinct from the development/engineering team, so that the project stays focused on product outcomes, rather than technical ones. At RMI, the "scrum lead" will almost alway be either the PM/PO or Tech Lead. ## Delivery Flow @@ -73,7 +73,7 @@ A ticket is ready when it has: - known dependencies, blockers or constraints - a size that fits inside a single sprint -If the ticket is too large to reason about, split it before bringing it into the sprint. +If the ticket is too large to close entirely in a single sprint (e.g. for code-work, closed with a single right-sized PR), then the ticket should be split before bringing it into sprint. ## Working Agreements diff --git a/process/okrs.md b/process/okrs.md index 9597276..7fd700c 100644 --- a/process/okrs.md +++ b/process/okrs.md @@ -68,6 +68,7 @@ Examples: - setting too many OKRs at once - measuring activity instead of impact - never using OKRs to make prioritization decisions +- lack of ambition; they aren't vanity metrics ## Practical Rule From dd6acc26f3a8724c93065997331955e1c176b1dc Mon Sep 17 00:00:00 2001 From: Jackson Hoffart Date: Thu, 26 Mar 2026 10:29:32 +0100 Subject: [PATCH 6/7] Allow "async" daily standups --- process/agile/ceremonies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/agile/ceremonies.md b/process/agile/ceremonies.md index f18058d..57aeddf 100644 --- a/process/agile/ceremonies.md +++ b/process/agile/ceremonies.md @@ -7,7 +7,7 @@ This document defines the sprint cadence. Teams may adapt the exact format, but | Ceremony | Frequency | Duration | Participants | Primary Output | | --- | --- | --- | --- | --- | | Sprint Planning | Every sprint | 1.5 to 2 hours | Core team, product owner | Sprint goal and committed work | -| Daily Scrum | Daily | 10 to 15 minutes | Core team | Shared plan and visible blockers | +| Daily Scrum | Daily | 10 min. OR Async in Shared Channel | Core team | Shared plan and blocker visibility | | Backlog Refinement | Weekly | 30 to 60 minutes | Product owner, Core team, subject matter experts as needed | Ready backlog | | Sprint Review | End of sprint | 1 to 2 hours | Core team, product owner, stakeholders | Feedback and accepted work | | Retrospective | End of sprint | 30 to 60 minutes | Core team | One or two improvements | From 04c26fa41dc5279542ab130567913fd2a36f91dc Mon Sep 17 00:00:00 2001 From: Jackson Hoffart Date: Thu, 26 Mar 2026 10:30:36 +0100 Subject: [PATCH 7/7] Remove "core team" from backlog refinement --- process/agile/ceremonies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/agile/ceremonies.md b/process/agile/ceremonies.md index 57aeddf..47ef18b 100644 --- a/process/agile/ceremonies.md +++ b/process/agile/ceremonies.md @@ -8,7 +8,7 @@ This document defines the sprint cadence. Teams may adapt the exact format, but | --- | --- | --- | --- | --- | | Sprint Planning | Every sprint | 1.5 to 2 hours | Core team, product owner | Sprint goal and committed work | | Daily Scrum | Daily | 10 min. OR Async in Shared Channel | Core team | Shared plan and blocker visibility | -| Backlog Refinement | Weekly | 30 to 60 minutes | Product owner, Core team, subject matter experts as needed | Ready backlog | +| Backlog Refinement | Weekly | 30 to 60 minutes | Product owner, subject matter experts or engineers as required | Ready backlog | | Sprint Review | End of sprint | 1 to 2 hours | Core team, product owner, stakeholders | Feedback and accepted work | | Retrospective | End of sprint | 30 to 60 minutes | Core team | One or two improvements |