feat: add OKR, agile and Jira delivery practices

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)

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 | 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 min. OR Async in Shared Channel | Core team | Shared plan and blocker visibility |
+| 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 |
+
+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.

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.

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, 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
+
+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 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
+
+- 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.

process/okrs.md

@@ -0,0 +1,75 @@
+# 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
+- lack of ambition; they aren't vanity metrics
+
+## Practical Rule
+
+If a team can complete every planned task and still miss the intended outcome, the OKR is not yet sharp enough.