team-process

name	team-process
description	Engineering team process patterns: OKR definition and scoring, sprint planning and retros, roadmap structuring (now/next/later), feature breakdown into user stories with acceptance criteria, and engineering metrics (DORA, velocity). For product lifecycle see product-lifecycle skill.

Team Process

Scope: Engineering team rituals, planning frameworks, and delivery metrics. For product discovery and PRD creation, see product-lifecycle. For feature breakdown into sprint tasks, use /breakdown.

When to Activate

• Writing OKRs for a quarter
• Running sprint planning or retrospectives
• Creating a product roadmap
• Defining engineering team metrics
• Structuring a feature into user stories and acceptance criteria
• Setting up team working agreements
• Reviewing an existing process for bottlenecks or missing feedback loops

---

OKR Framework

Structure

Objective (qualitative, inspiring, 1 sentence):
  "Become the fastest checkout experience in our category"

Key Results (measurable, 3-5 per objective):
  KR1: Reduce checkout time from 120s to 45s (median)
  KR2: Increase checkout completion rate from 68% to 82%
  KR3: Achieve p95 checkout latency < 2s on mobile
  KR4: 0 payment data incidents this quarter

OKR quality checklist

• Objective is qualitative and inspiring (no metrics in the objective itself)
• Each KR is measurable with a specific number
• KRs are outcomes, not activities ("increase X from A to B" not "do Y")
• 3-5 KRs per objective (not 10)
• Stretch: 70% achievement = good (not 100%)
• Baseline established for each KR before quarter starts

OKR anti-patterns

Anti-pattern	Example	Fix
Activity KR	"Launch feature X"	"Feature X increases activation by 15%"
Sandbagging	KR you'll hit 100% easily	Set 70% = good
Too many	8 objectives × 5 KRs = 40 KRs	Max 3 objectives × 4 KRs
No baseline	"Improve response time"	"Improve p95 latency from 800ms to 300ms"
Vanity metric	"Reach 100k users"	"90-day retention reaches 40%"

OKR scoring

At quarter end:

• 0.7–1.0: Strong (if consistently 1.0, your targets were too easy)
• 0.4–0.6: Partial — review blockers
• < 0.4: Missed — root cause analysis required

---

Sprint Planning

Sprint structure (2-week sprints)

Day 1:   Sprint planning (1-2h)
Days 2-9: Execution (daily standup 15min)
Day 10:   Code freeze + testing
Day 11:   Sprint review (30min) + Retrospective (1h)
Day 12:   Buffer / planning for next sprint

Sprint planning agenda

1. Capacity (10 min): How many story points can we commit?

   • Default team velocity × 0.8 (leave 20% buffer for unplanned)
   • Account for PTO, interviews, on-call

2. Backlog refinement (20 min): Review top stories from backlog

   • Stories must have acceptance criteria before entering sprint
   • Stories > 5 pts must be broken down

3. Commitment (20 min): Select stories for the sprint

   • Fill to capacity × 0.8
   • Assign owners for each story

4. Sprint goal (5 min): One sentence summarizing the sprint's theme

Sprint goal format

By end of sprint [N], users will be able to [capability], which delivers [value].

Daily standup (async-friendly format)

Yesterday: [what I completed]
Today:     [what I'm working on]
Blockers:  [what's blocking me, who I need help from]

Retrospective formats

Start/Stop/Continue (default):

• Start: what should we begin doing?
• Stop: what's hurting us that we should stop?
• Continue: what's working well?

4Ls (for deeper reflection):

• Liked: what went well?
• Learned: what did we learn?
• Lacked: what was missing?
• Longed for: what do we wish we had?

Action item format:

Action: [specific action]
Owner: [one person, not "the team"]
Due: [next sprint / specific date]

---

Roadmap Structuring

Now / Next / Later format

Horizon	Timeframe	Status	Commitment level
Now	Current quarter	In progress or committed	High — specific features
Next	Next 1-2 quarters	Planned	Medium — themes and epics
Later	6+ months	Exploratory	Low — opportunities, not commitments

Roadmap item format

[Theme/Epic] — [one-line description]
Value: [outcome for users]
Metrics: [how we'll measure success]
Status: [Now / Next / Later]
Dependencies: [teams or external]

Roadmap anti-patterns

• Feature factory: listing features without outcomes — always state the user value
• Over-committing Later: Later items should be opportunities, not promises
• Missing dependencies: calling out what blocks what
• No metrics: every item should have a measurable success criteria

---

Engineering Metrics

DORA (DevOps Research and Assessment) metrics

Metric	Elite	High	Medium	Low
Deployment frequency	Multiple/day	Weekly	Monthly	< Monthly
Lead time for changes	< 1 hour	1 day	1 week	> 1 month
Change failure rate	< 5%	10%	15%	> 30%
MTTR	< 1 hour	< 1 day	< 1 week	> 1 week

Measuring DORA

-- Deployment frequency (deploys per day, 30-day window)
select
  count(*) / 30.0 as deploys_per_day
from deploys
where deployed_at >= now() - interval '30 days'
  and environment = 'production';

-- Change failure rate
select
  count(case when caused_incident then 1 end) * 1.0 / count(*) as failure_rate
from deploys
where deployed_at >= now() - interval '30 days';

-- MTTR (mean time to recovery)
select
  avg(extract(epoch from (resolved_at - started_at)) / 3600) as mttr_hours
from incidents
where resolved_at is not null
  and started_at >= now() - interval '90 days';

Team health metrics

Metric	How to measure	Target
Velocity	Story points per sprint	Stable (not maximized)
Unplanned work %	Unplanned pts / total pts	< 20%
Cycle time	Story created → merged	< 3 days
PR size	Lines changed per PR	< 400 lines
Test coverage	% branches covered	≥ 80%
On-call burden	Pages per engineer per week	< 2

---

Working Agreements Template

## Team Working Agreements — [Team Name]

### Communication
- Default async: Slack for non-urgent, PR comments for code
- Response time: < 4h during business hours for direct messages
- Meeting-free blocks: Tuesday and Thursday 9am-12pm

### Code review
- PRs reviewed within 1 business day
- At least 1 approver required; 2 for core systems
- PR size: keep under 400 lines; break up larger changes

### On-call
- Rotation: 1 week per engineer, team of [N] = 1 week every [N] weeks
- Handoff: 30min sync at rotation end
- Runbook for every alert

### Definition of done
- Unit tests written and CI passing
- PR reviewed and approved
- Deployed to staging and manually tested
- Product sign-off for user-visible changes
- Docs updated if behavior changed

### Meetings
- All meetings have an agenda sent 24h before
- Decisions documented in the meeting notes within 24h
- Recurring meetings reviewed monthly for relevance

---

Engineering Metrics — DORA + SPACE

Engineering team effectiveness is measured with the DORA Four Keys framework and complemented by the SPACE framework for developer experience.

DORA Four Keys (measurement layer)

Metric	Elite	High	Medium	Low
Deploy Frequency	Multiple/day	Daily–weekly	Weekly–monthly	< Monthly
Lead Time	< 1h	1d–1wk	1wk–1mo	> 1mo
Change Failure Rate	0–15%	16–30%	16–30%	46–60%
MTTR	< 1h	< 1d	1d–1wk	> 1wk

Team level = lowest single-metric rating. Use for team improvement — never for individual performance evaluation (Goodhart's Law).

Monthly Review Cadence

Use /engineering-review for structured monthly reviews combining DORA trends, leading indicators (PR size, CI duration, review turnaround), tech debt movement, and team wellbeing signals.

Quarterly DevEx Survey

Use /devex-survey to design anonymous developer experience surveys. Measures: Flow State, Feedback Loops, Cognitive Load, Collaboration, Wellbeing.

Related

• product-lifecycle — product discovery, idea → PRD
• incident-response — MTTR improvement, incident process
• engineering-metrics — DORA Four Keys, SPACE framework theory
• dora-implementation — technical DORA data extraction
• /breakdown command — break epic into sprint-ready stories
• /prd command — write a Product Requirements Document
• /dora-baseline command — measure team's current DORA baseline
• /devex-survey command — design a developer experience survey
• /engineering-review command — monthly engineering health review