Delivery Methodologies

Choose delivery methods for the risks and demand each team faces. Share outcomes across teams, measure flow and adapt capacity around review and verification.

Why this matters

A delivery method determines when teams learn, how they handle interruptions and what promises they can support. An interrupt-driven platform team and an exploratory AI team may need different methods.

Assess planned work, uncertainty, external commitments and dependencies. AI coding tools add pressure on review, evaluation and security capacity. Chapter 06 covers the execution practices beneath these choices.

The methods and what each one optimizes

Waterfall, and when it still fits

Waterfall is plan-driven, phase-gated delivery: requirements, design, build, test and deploy run in sequence, each closed by a sign-off. Scope is fixed early, and time and cost are estimated from it.

Royce’s 1970 paper describes sequential delivery, then warns of its risk and recommends iteration. Wheeler and others highlight this qualification. The influence of misreading versus fixed-price procurement on waterfall adoption remains debated.

Snowden’s Cynefin separates ordered problems, understood through known relationships or expert analysis, from complex problems understood through action. New customer-value and AI-behavior questions need empirical feedback.

But waterfall still fits some B2B work:

• Ordered problems with a known target state, such as a data-residency migration with a known schema and cutover plan.
• Fixed external scope and dates you don’t control: a contractual deliverable, a certification audit, a regulatory documentation deadline.
• Long lead times where late change is very expensive: hardware, firmware, or a partner integration tied to the partner’s release train.

Within fixed commitments, build small tested increments and gather feedback every week or two.

The Agile Manifesto

Seventeen practitioners published the Agile Manifesto in February 2001. Its four values, paraphrased:

• People and interactions over process and tools.
• Working software over exhaustive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

The manifesto values the right-hand items too, while preferring the left-hand ones when they conflict.

Enterprise contracts still matter. Where possible, shape commitments around outcomes, dates and explicit uncertainty, preserving room to iterate on implementation.

Fowler’s 2018 Agile Industrial Complex critique opposes imposed process. He favors team choice, technical excellence and long-lived products. Make organizational forecasting, compliance and coordination needs explicit, then let teams choose within those bounds.

Scrum

Schwaber and Sutherland’s November 2020 Scrum Guide defines a lightweight, deliberately incomplete framework based on empiricism and lean thinking. It specifies:

Several Scrum Teams on one product share one Product Goal, one Product Backlog and one Product Owner.

Scrum creates regular inspection through working increments and reviews. Heavy interrupt demand can undermine planned Sprint Goals unless capacity accounts for it.

Write Sprint Goals as outcomes or learning. Use Sprint Reviews for customer evidence: show the increment against the goal and measure, with design partners or customer success involved.

In 2025, Sutherland, John Coleman and Ralph Jocham published the Scrum Guide Expansion Pack, optional guidance alongside the unchanged 2020 Guide. Its AI section asks teams to keep outcomes, quality and learning under control so that speed produces value rather than faster failure.

Product Owner versus product manager

The Scrum Guide makes the Product Owner accountable for maximizing the value of the team’s work, for developing and communicating the Product Goal, and for ordering the Product Backlog. The PO may delegate the work but keeps the accountability. In the Guide’s words, “The Product Owner is one person, not a committee.”

Product management also covers discovery, strategy, pricing, go-to-market and leadership. Cagan’s 2011 critique argues that separating an outward PM from an inward backlog owner risks fragmented ownership and lost customer knowledge.

Where roles split, retain direct customer contact for the Product Owner. Include them in calls and design-partner work, assign outcomes and agree decision rights. Technical backlog depth can justify the split without reducing the role to a ticket proxy.

Kanban and flow

The May 2025 Kanban Guide, by Vacanti, Coleman and contributors, defines workflow, active work management and continuous improvement. Make start, finish and policies explicit. Control work in progress and aging, using four flow metrics:

A service level expectation (SLE) combines duration and probability, such as 85% within eight days. Base it on historical cycle time or an initial estimate. The 2025 Guide places it in the Definition of Workflow and renames Kanban measures as flow metrics.

Little’s Law (1961) relates average cycle time to average WIP divided by average throughput in a stable system. At constant throughput, lower WIP reduces average cycle time.

Kanban fits teams whose demand is interrupt-driven: platform, integration and connector teams, security fixes and customer escalations. Your levers are WIP limits per state, classes of service (for example, an expedite lane for a P1 customer escalation that may break the WIP limit, used sparingly), and an SLE that sales and customer success can quote. “Connector bugs reported by a paying customer: 85% fixed within ten working days” is more useful to an account team than any roadmap slide.

Shape Up

Ryan Singer’s Shape Up, published by Basecamp with a foreword by Jason Fried, describes a method built around fixed time and variable scope:

• Six-week cycles, followed by a two-week cool-down for bugs, small fixes and planning the next cycle.
• Appetite: how much time the business wants to spend on a problem, decided before anyone designs a solution. An estimate starts from a design and asks how long; an appetite starts from a time budget and asks what design fits.
• Shaping: a small senior group works the problem until it’s rough enough to leave room for the team, solved enough that the main elements are clear and bounded enough that everyone knows what’s out. The result is a pitch with five ingredients: problem, appetite, solution, rabbit holes and no-gos.
• The betting table: during cool-down, stakeholders choose which pitches to bet the next cycle on. Singer calls the stance “bets, not backlogs”: unchosen pitches aren’t queued.
• The circuit breaker: a project that doesn’t ship by the end of its cycle is cancelled by default, not extended. Teams are uninterrupted during the cycle and own their scope.
• Hill charts, which show work moving uphill (figuring it out) and then downhill (executing what’s known).

Enterprise teams must fit Shape Up around quarterly plans and escalations. Appetite transfers readily: fix the investment, then shape and cut scope to fit.

Dual-track agile

Desiree Sy described the pattern in 2007 for fitting UX work into agile teams. Marty Cagan popularized the name dual-track agile in 2012, and Jeff Patton wrote an explainer in 2017 (updated in 2023) that credits Sy and corrects common misreadings.

Two kinds of work run in parallel. Discovery is fast, cheap learning (hypotheses, time-boxed experiments, prototypes) ending in a decision to build, kill or keep learning. Delivery is predictable, releasable, high-quality software.

Keep discovery and delivery within one team. The trio spends more time in discovery, while the team shares the learning. Discovery should change or stop ideas rather than merely confirm them.

Cagan later dropped the label for “continuous discovery and continuous delivery,” because the name pushed people toward process diagrams. The practice is what matters: the backlog receives only items that passed a discovery test (Chapter 01 covers the discovery habits themselves).

Scaled frameworks

Scaled frameworks solve a coordination problem: many teams working on one product or portfolio with dependencies between them.

SAFe (the Scaled Agile Framework) groups teams into Agile Release Trains that plan together in Planning Intervals, cadence-based timeboxes typically 8 to 12 weeks long, usually four or five iterations plus an Innovation and Planning iteration. SAFe prioritizes with WSJF (weighted shortest job first), which divides cost of delay by job duration, where cost of delay sums relative estimates of user and business value, time criticality, and risk reduction or opportunity enablement. SAFe credits the approach to Don Reinertsen’s work on product development flow. In June 2026 Scaled Agile released AI-Native SAFe alongside Core SAFe, arguing that the bottleneck has moved from building software to verifying that what’s built is safe, secure and valuable.

SAFe criticism remains contested opinion. Fowler and Snowden challenge imposed process and coordination overhead. PMs report large planning events and release coordination encouraging bigger batches. Defenders argue later versions address these concerns.

LeSS (Large-Scale Scrum) takes the opposite approach: one Product Owner, one Product Backlog, one common Sprint and one shippable increment for the whole product. Basic LeSS covers up to eight teams of about eight people; LeSS Huge extends the same structure to a few thousand. LeSS insists on cross-functional feature teams rather than single-specialty teams, and describes itself as deliberately simple.

Before scaling coordination, identify dependencies removable through stable APIs, contracts or self-service capabilities. Coordinate those that remain necessary.

Choosing a method

Five questions get you most of the way:

1. How much is known? Ordered problems tolerate planning; complex ones need short feedback loops.
2. Where is the main risk? Cagan’s four risks (value, usability, feasibility, viability, covered in Chapter 00) point to different methods. Value and usability risk need discovery and frequent review. Feasibility risk needs spikes and prototypes. Viability risk needs stakeholders in the loop.
3. What’s been promised externally? Fixed dates, fixed scope, contractual deliverables and service levels.
4. How interrupt-driven is demand? When a large share of the team’s work arrives unplanned, a Sprint plan keeps breaking.
5. How many teams share the code, and how strong is the test and eval automation? Coordination cost and verification cost both shape batch size.

The figure below places most teams; the methodology selection guide in the artifacts section adds the remaining cases, including fixed-date bets (appetite-bounded cycles), many teams on one product (remove dependencies, then scale) and agent-heavy teams with strong automation (continuous flow with a fixed review cadence).

Choose per team. Legacy migrations and exploratory agents face different risks. Share the North Star, quarterly outcomes, leadership review cadence and customer-facing quality standard.

RICE in depth

RICE structures prioritization within the delivery cadence. Sean McBride introduced it at Intercom in 2018 to expose reach, impact, confidence and effort. Chapter 03 compares alternative frameworks.

The score is reach times impact times confidence, divided by effort. McBride describes it as “total impact per time worked.”

Intercom treats RICE as guidance. Dependencies and table stakes can override score order. Check seven pitfalls:

1. Confidence by conviction. Teams assign 80% because they feel sure. Itamar Gilad’s Confidence Meter, built for a different scoring model, makes the fix concrete: opinions and self-conviction count for almost nothing, and confidence rises only with evidence such as research, data and launch results. Label the evidence behind every confidence score and cap confidence by label.
2. Reach in the wrong unit. A feature used by 40 people at your three largest accounts may matter more than one used by 4,000 at small accounts. Define reach as accounts or ARR touched per quarter, and use one unit across the sheet.
3. Impact drift between scorers. One PM’s “massive” is another’s “high.” Calibrate with two or three reference items.
4. Effort counts only the code. Coding agents lower build effort. They don’t lower review, evals, security review, migration, documentation or enablement. Estimate effort to “safely in production and adopted.”
5. False precision. A score of 2,400 against 2,350 is noise. Group results into bands.
6. No cost of delay. RICE has no term for time, so a contractual deadline or a legacy system that costs more each month doesn’t move the score. WSJF puts time criticality in the numerator; re-score the top of a RICE list with it.
7. Mixed grain. A two-day fix and a two-quarter platform investment don’t belong on the same sheet. Score initiatives against initiatives.

Let the harness gather the evidence. Ask it, through connectors to product analytics and the CRM, how many accounts hit the relevant workflow last quarter and how much ARR they represent, then ask it to name the weakest assumption in each row.

Delivery choices are pricing signals

Delivery affects pricing expectations. Free betas can anchor free access. Top-tier-first releases signal premium value. Pilot limits can become commercial anchors. Decide timing, packaging and limits with the pricing owner. Chapters 12 and 15 cover the offer and pricing decisions.

How to apply it

Here’s a method for setting up, or resetting, the delivery system for a product with one or more teams. Plan on about a month for the first pass, then a quarterly review.

Week 1: Diagnose the work.

1. Write the outcome layer first. Confirm the North Star and the quarter’s outcome goals. Every team’s method has to serve these.
2. Classify each team’s work. From the last two quarters of finished work, how much was planned and how much unplanned? How much was ordered and how much complex? Ask the harness for this breakdown from the tracker, with examples, and check a sample yourself.
3. Name the main risk per team. Value risk needs discovery and customer review; feasibility risk needs spikes and prototypes; interruptions need flow management.
4. List external commitments: fixed dates, fixed scope and published service levels. Note which are truly fixed and which are fixed because nobody has asked.

Week 2: Choose and agree.

5. Choose a default method per team with the selection guide, with one paragraph on why and what would make you change it.
6. Write a team working agreement with each team. The team writes it; you make sure the organization’s real needs (forecasts, compliance, service levels) are in it.
7. Set appetites for fixed-date work. Decide what each commitment is worth and what scope can be cut, and write the circuit breaker in advance.

Week 3: Instrument.

8. Set up flow reporting for every team, whatever its method: WIP, throughput, work item age and cycle time, plus age in review and verification states.
9. Publish an SLE for each class of interrupt work, and give it to customer success and sales.

Week 4: Prioritize and review.

10. Score the next quarter’s initiatives with RICE, with reach in accounts or ARR, evidence labels on confidence and full effort to production. Re-score the top items with cost of delay, and record every override with its reason.
11. Run reviews as evidence forums that end with the decisions needed.

Every quarter:

12. Run the process health check with each team, and pick at most two changes. Change the method only when the work has changed, not because a quarter went badly.

The AI lens

Building AI-powered products

AI features change what “done” means. Chapter 31 covers building AI products in depth; for delivery, three changes matter.

• Evals belong in the Definition of Done. An AI feature is done when it meets its quality bar on an eval set that reflects real use, and that eval runs on every change. Ship without updated evals and nobody can safely change the feature next Sprint.
• AI work is complex. Model behavior on real customer data can’t be fully known by analysis, which puts most AI feature work in Cynefin’s complex domain. Expect more discovery and more scope cuts; appetites work better than estimates.
• Cost per task is a delivery constraint. Inference cost scales with use, so a feature can pass every functional test and still damage the margin. Put a cost-per-task check in the Definition of Done for features that call models.

Doing the work with AI

Coding agents now write, test and propose changes. Productivity evidence remains mixed:

• The slowdown result. In a July 2025 randomized trial, METR found that 16 experienced open-source developers, working on 246 real issues with early-2025 AI tools, took 19% longer with AI, while believing it had made them about 20% faster.
• The update. In February 2026, with late-2025 tools, METR’s estimates moved to modest speedups (about 18% for returning developers and about 4% for new ones) with wide uncertainty. METR called this weak evidence, partly because developers increasingly refused to work without AI.
• The amplifier finding. DORA’s 2025 research concluded that AI acts mainly as an amplifier of an organization’s existing strengths and weaknesses. Its AI Capabilities Model, built from almost 5,000 survey responses and 78 interviews, names seven capabilities that decide whether AI helps, including working in small batches, strong version control and quality internal platforms.
• The delegation picture. Anthropic’s 2026 Agentic Coding Trends Report, a vendor document best read as direction of travel, reports that developers use AI in about 60% of their work but fully delegate only 0 to 20% of tasks. It also reports that 27% of AI-assisted work would not otherwise have been done: more experiments, and more things nobody asked for.
• The discipline. Kent Beck’s 2025 writing on “augmented coding” keeps the human accountable for code quality and tests, and treats an agent disabling tests as a warning sign. AI-Native SAFe makes the same point from the framework side: the bottleneck has moved to verification.

Read together, these point to six implications for your delivery system:

1. Shrink batch size. Agents make large changes cheap to produce and expensive to review. Keep changes small anyway, as DORA’s small-batches capability says.
2. Treat verification as the constraint. Review, evals, security approval and customer adoption are where work now waits. Give them explicit states on the board, WIP limits and age tracking.
3. Separate the build loop from the review loop. A two-week Sprint may be too slow a loop for building and still right for customer review and retrospectives. Consider continuous flow for delivery with a fixed cadence for review, retro and planning.
4. Stop relying on velocity. When a three-day story takes three hours, story points lose meaning. Throughput of verified outcomes and cycle time are steadier measures.
5. Spend the cheaper build on discovery. Prototypes take hours, so discovery can test more ideas. The risk moves to building things nobody needs, so discovery has to kill more.
6. Put agents in the working agreement. Which code agents may change, who reviews what, and what agents may never do (disable tests, edit eval suites, touch approval gates).

Using the harness for delivery work

Use approved tracker, source, analytics and CRM connectors for flow reports, oldest-item lists, sourced reach estimates and review drafts. Ask for weak assumptions. Interpret the evidence and choose the decisions.

The Beacon case: one product, three methods

The diagnosis. The harness classifies two quarters of tracker data. Correlate’s work is mostly planned and ordered: migration tickets with a known target state. Connectors and platform spends close to half its time on unplanned escalations and partner requests, and has missed most Sprint Goals. Diagnose and Act are doing complex AI work whose main risk is whether responders trust the agent. Learn, which feeds resolved incidents back into retrieval and evals, faces large unknowns.

Five teams, three methods. You propose a split, and the teams adjust it:

All five share the North Star (incidents resolved with Beacon’s help per week), one quarterly outcome review and one monthly product review with customer success, so leadership compares the teams on outcomes and flow rather than on ceremonies.

Fixed date, variable scope. Northlight Live won’t move. You set an appetite of two six-week cycles for supervised remediation, shaped as a pitch with explicit no-gos: no new runbook actions beyond restart, roll back and scale; autonomous execution only for low-risk actions the customer allowlists. The circuit breaker is written down before the first cycle starts: if autonomous rollback isn’t proven safe on the eval set by the end of cycle two, it ships approval-gated only. Marcus gets a date to plan around, and Sam gets a scope to review.

The RICE sheet. For next quarter, you score five initiatives with reach in accounts per quarter (out of about 420 customers), confidence capped by evidence label and effort counted to production:

Effort changes ranking: adding evaluation, security review and communication triples the citation estimate from one to three person-months. Reach hides value: eighteen MSP partners serve many tenants, so ARR exposure supports an override. RICE omits delay: AI Act documentation supports EU renewals and Classic migration costs increase monthly. WSJF raises both above billing instrumentation. Record these overrides and keep billing for the pricing dependency.

Agents and batch size. The flow report confirms what leadership suspected. Opened pull requests have risen sharply, but the oldest items on the Diagnose and Act boards all sit in “in review.” The change behind the hallucinated root cause was one of them: a large, mostly agent-written change to retrieval logic, approved on a few manual spot checks, before the team had an eval suite. The teams add a WIP limit on “in review,” a size guideline for agent-generated pull requests and an eval gate that blocks merging when diagnosis quality drops on the regression set. Their working agreement gains a clause: agents may open pull requests in Diagnose and Act code; any change touching the Act approval gate needs two human reviewers and Sam’s security sign-off; agents may not change or disable eval suites.

Cost in the Definition of Done. Beacon’s gross margin fell from 81% to 72% after agentic features launched, on inference cost. Diagnose features now carry an inference-cost-per-resolved-incident check, reviewed with the same weight as quality.

The scaling debate. Northlight leadership raises SAFe across Observe, Desk and Beacon. You argue for a LeSS-style single backlog and Product Goal for Beacon, connector and API contracts to cut dependencies between products, and a quarterly portfolio review for what remains. The VP of Product hasn’t decided, and you’ve framed it as a choice about coordination cost rather than about frameworks.

Product 360 artifacts

# Methodology selection guide · [Product] · [Team] · [Date]

**Owner:** [PM]   **Agreed with:** [tech lead, designer, team]   **Review by:** [Date]

## 1. The work (last two quarters, from the tracker)
- Share of work planned vs unplanned: [x]% / [y]%
- Share of work ordered (known solution) vs complex (learning required): [x]% / [y]%
- Typical item size: [hours / days / weeks]
- Examples of each category: [three links]

## 2. The main risk (Chapter 00's four risks)
Value / Usability / Feasibility / Viability, with evidence:

## 3. External commitments
| Commitment | Type (date, scope, service level) | Truly fixed? | Owner | Date |
|---|---|---|---|---|
| | | | | |

## 4. Coordination
- Teams sharing this codebase or backlog:
- Dependencies that could be removed by an API, contract or platform capability:

## 5. Verification strength
- Automated tests: strong / partial / weak
- Evals for AI behavior: strong / partial / weak / not applicable
- Share of changes written mainly by coding agents:

## 6. Default method
| Situation | Default |
|---|---|
| Ordered, fixed external date and scope | Plan-driven, iterative build inside gates |
| Complex, value risk high | Scrum with dual-track discovery |
| Interrupt-driven, service commitments | Kanban with WIP limits and an SLE |
| Fixed date, flexible scope | Appetite-bounded cycles (Shape Up style) or Scrum with appetites |
| Five or more teams, real dependencies | Remove dependencies first; then LeSS, or SAFe for portfolio governance |
| Agent-heavy, strong CI and evals | Continuous flow with a fixed review, retro and planning cadence |

**Chosen method:** [method]
**Why (one paragraph):**
**What would make us change it:** [specific trigger, e.g. unplanned work above an agreed share for two months]

# Team working agreement · [Team] · v[n] · [Date]

**Method:** [Scrum / Kanban / cycles / hybrid]   **Signed off by:** [team members]   **Review date:** [Date]

## Cadence
- Planning or betting: [when, how long]
- Daily coordination: [when, 15 minutes]
- Review with customers or customer-facing staff: [when, who is invited]
- Retrospective: [when]

## Workflow and WIP limits
| State | Entry policy | WIP limit |
|---|---|---|
| Ready | | |
| In progress | | |
| In review | | |
| Evals and security | | |
| Ready to release | | |

## Definition of Done
- [ ] Tests pass, including tests not written solely by an agent
- [ ] Evals updated and passing (AI features)
- [ ] Cost per task within budget (features that call models)
- [ ] Security review complete where required
- [ ] Documentation and release note written
- [ ] Customer-facing teams told what changed

## Coding agents
- Agents may change: [code areas]
- Agents may not change: [eval suites, test configuration, approval gates, security controls]
- Human review required: [one reviewer by default; two for these areas]
- Size guideline for agent-generated changes: [e.g. reviewable in one sitting]
- An agent disabling or deleting a test is treated as a defect.

## Interrupt work
- How escalations enter: [channel, triage owner]
- Classes of service: Expedite (may exceed WIP; criteria) / Standard / Fixed date
- Service level expectation: [x]% of [item type] finish within [n] days

## Decision rights
| Decision | Decides | Consulted |
|---|---|---|
| What problem to solve next | PM | Team, design, tech lead |
| How to solve it | Team | PM, design |
| Scope cuts inside an appetite | Team with PM | Stakeholders informed |
| Release readiness | Tech lead | PM, security |

## Meeting norms
[Start and end times, async defaults, recording, decisions written down]

# RICE scoring sheet · [Product] · [Quarter] · [Date]

**Goal metric all items are scored against:** [one metric]
**Reach unit:** accounts / ARR / users / events per [quarter]   (use one unit for the whole sheet)
**Calibration items:** [two or three reference items with agreed scores]

| ID | Initiative | Reach (unit, period, source) | Impact (3 / 2 / 1 / 0.5 / 0.25, rationale) | Confidence (100 / 80 / 50%, evidence label) | Effort (person-months to production and adoption) | RICE | Cost-of-delay note | Override? (dependency, table stakes, commitment) | Decision |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

Score = (Reach × Impact × Confidence) ÷ Effort.

## Evidence labels and confidence caps
| Evidence | Maximum confidence |
|---|---|
| Opinion or conviction | 50% |
| Anecdotes, a few customer requests | 50% |
| Interviews across personas, or usage data | 80% |
| Test result, pilot or incident evidence | 100% |

## Effort includes
Build, review, evals, security review, migration, documentation, enablement, support readiness.

## Review questions
1. Which three rows have the weakest evidence?
2. Which items have a deadline or rising cost that RICE ignores?
3. Which items differ by less than the noise? Treat them as ties.
4. Is every item at the same grain (initiatives, not tickets)?

# Shaped bet · [Name] · [Date]

**Shaped by:** [names]   **Cycle:** [dates]   **Team:** [team]

## Problem
[The specific customer problem, with evidence: incidents, interviews, data]

## Appetite
[Small batch: 1 to 2 weeks / Big batch: 6 weeks / other]. This is a budget, not an estimate.

## Solution (rough, solved, bounded)
[The main elements and how they fit, at the level of a sketch]

## Rabbit holes
[Known technical or design traps, and how we avoid them]

## No-gos
[What is explicitly out of scope]

## Circuit breaker
If not shippable by [date], we [ship this reduced scope / stop and re-pitch]. We do not extend by default.

## Outcome signal
[The metric and threshold that tells us this worked, and when we'll check]

# Review · [Team] · [Sprint or cycle n] · [Date]

**Attendees:** [team, PM, customer success, design partner]

## Goal
Sprint Goal or bet: [text]
Met / Partly met / Not met, with one line why:

## What shipped
| Item | Linked to goal? | Released to | Evidence it works |
|---|---|---|---|
| | | | |

## Outcome metric
[Metric]: [value before] → [value now]. Too early to tell? Say when we'll know.

## Customer evidence
[Demo feedback, design-partner reactions, support signals, quotes with source]

## What we learned in discovery
- Ideas tested:
- Killed:
- Moving to delivery:

## Flow
- Throughput: [items finished]
- Cycle time, 85th percentile: [days]
- Oldest unfinished item and its state: [item, age]
- Age in review and verification: [days]

## Risks and decisions needed
| Decision | Owner | By when |
|---|---|---|
| | | |

## Next goal
[Draft Sprint Goal or next bet]

# Process health check · [Team] · [Quarter] · [Date]

Score each from 1 (poor) to 5 (strong) with evidence. Pick at most two to improve next quarter.

| # | Dimension | Score | Evidence |
|---|---|---|---|
| 1 | Goals are outcomes, not output | | |
| 2 | WIP stays within limits | | |
| 3 | Cycle time trend is stable or improving | | |
| 4 | Few items age past the SLE | | |
| 5 | Changes are small (batch size) | | |
| 6 | Review and verification wait time is short | | |
| 7 | Escaped defects and incidents are low | | |
| 8 | Discovery kills or reshapes ideas before build | | |
| 9 | PM and team have regular direct customer contact | | |
| 10 | Agent-generated changes have a low revert rate | | |
| 11 | The team reports a sustainable pace | | |
| 12 | Every ceremony produces a decision or a change | | |

## Two changes for next quarter
1. [Change], owner, how we'll know it worked:
2.

## Method still fits?
Has the work changed (share unplanned, complexity, commitments, team count)? Yes / No. If yes, rerun the selection guide.

Prompts

Goal: Get a reasoned default method for one team, based on its actual work rather than habit.
Paste in (or connect the harness to): the team's tracker for the last two quarters, its current method, the product's outcome goals and a list of external commitments. Use an approved tool if the tracker contains customer names.

You are helping me choose a delivery method for [team] on [product].

1. From the tracker, estimate the share of work that was planned vs unplanned, and ordered (known solution) vs complex (learning required). Give three example items for each category with links.
2. Identify the main risk for this team: value, usability, feasibility or viability. Cite the evidence.
3. List the external commitments and mark which look truly fixed.
4. Recommend a default method from: plan-driven with iterative build inside gates; Scrum with dual-track discovery; Kanban with WIP limits and an SLE; appetite-bounded cycles; continuous flow with a fixed review cadence. Explain why in one paragraph.
5. State the specific trigger that should make us revisit the choice.

Don't recommend a scaled framework unless more than four teams share this backlog. Flag any number you estimated rather than counted.

Check the output: open five of the example items and confirm they're classified correctly. If the planned/unplanned split looks wrong, the recommendation is wrong too.

Goal: Produce a first draft the team can edit, covering cadence, WIP, Definition of Done and agent use.
Paste in: the chosen method, the team's current workflow states, any existing Definition of Done, security and compliance requirements, and how escalations arrive today.

Draft a team working agreement for [team] running [method]. Include:
- Cadence for planning or betting, daily coordination, review (with who from outside the team attends) and retrospective.
- Workflow states with entry policies and a proposed WIP limit for each, including explicit "in review" and "evals and security" states.
- A Definition of Done that includes tests, evals and cost-per-task checks for AI features, security review where required, documentation and customer-facing communication.
- Rules for coding agents: what they may change, what they may never change (eval suites, test configuration, approval gates), required human reviewers and a size guideline for agent-generated changes.
- Classes of service for interrupt work and a starting SLE, labeled as a guess until we have data.
- A decision-rights table for PM, tech lead, designer and team.

Mark every item you invented rather than took from my inputs with [proposed].

Check the output: the team, not you, should own the final version. Bring the draft to a retrospective and expect half the [proposed] items to change.

Goal: Replace guessed reach and confidence with evidence from company systems.
Paste in (or connect the harness to): the list of candidate initiatives, product analytics, CRM and support ticket data. Use only tools approved for customer data.

For each initiative below, for the last full quarter:
1. Reach: how many accounts used the affected workflow, and how much ARR those accounts represent. Show the source and the definition you used.
2. Signal strength: how many support tickets, CRM notes or sales-call summaries mention the problem, with three examples each.
3. Evidence label: opinion, anecdote, interviews, usage data, or test/pilot/incident evidence, based only on what you found.

Present a table with one row per initiative. Don't assign impact or effort; I'll do that with the team. If you can't find data for a field, write "no data" rather than estimating.

[initiatives]

Check the output: spot-check two reach numbers against the source system yourself. Confirm the workflow definition matches what the initiative actually changes.

Goal: Find the scores most likely to be wrong before the sheet drives a quarter's plan.
Paste in: the completed RICE sheet with rationales, the goal metric and any known deadlines or commitments.

Act as a skeptical product leader reviewing this RICE sheet for [product].

1. For each row, name the weakest assumption (reach, impact, confidence or effort) and what evidence would test it.
2. Flag any confidence score higher than its evidence supports.
3. Flag any effort estimate that seems to count only code, not review, evals, security, migration, documentation and enablement.
4. Identify items with a deadline or rising cost over time. Re-score the top eight with WSJF (cost of delay as user and business value + time criticality + risk reduction or opportunity enablement, divided by job duration), using relative estimates, and show where the order changes.
5. Identify items whose scores differ by less than the noise, and treat them as ties.
6. Check that all items are at the same grain.

Preserve the supplied numbers. Present proposed revisions separately with reasons.

Check the output: the useful result is the list of disagreements, not a new ranking. Take the top three to the team and decide them together.

Goal: Turn tracker and metric data into a review that shows outcomes and asks for decisions.
Paste in (or connect the harness to): the Sprint Goal or bet, the items finished, the outcome metric before and after, customer feedback from the period, and flow data from the tracker.

Draft a review for [team], [Sprint or cycle], with these sections: goal and whether it was met; what shipped and whether each item links to the goal; outcome metric movement (say "too early to tell" if it is); customer evidence with sources; discovery results (tested, killed, moving to delivery); flow (throughput, 85th percentile cycle time, oldest unfinished item and its state, age in review and verification); risks and decisions needed with owners; and a draft next goal.

Keep it to one page. Don't describe items that don't link to the goal in more than one line. Quote customer feedback verbatim with source; never paraphrase inside quotation marks.

Check the output: the "decisions needed" section is the reason the review exists. If it's empty, ask yourself what you need from the room before you send it.

Goal: Find where work is waiting, and whether coding agents have moved the bottleneck.
Paste in (or connect the harness to): the tracker and source control history for the last two quarters, the team's working agreement and its WIP limits.

For [team], analyze delivery flow over the last two quarters:
1. WIP, throughput, cycle time (median and 85th percentile) and work item age, by month.
2. Time spent in each workflow state, especially review, evals and security approval. Which state holds the oldest items?
3. Size of changes over time, and the share written mainly by coding agents. Compare revert and escaped-defect rates for large vs small changes and for agent-heavy vs other changes.
4. How often WIP limits were exceeded, and by which classes of work.
5. Score the team from 1 to 5 on each dimension of the process health check below, citing evidence.

Separate observation from interpretation. Label causal explanations as hypotheses unless the evidence establishes them.

[process health check dimensions]

Check the output: walk the board with the team and confirm the oldest items are stuck where the analysis says. Pick at most two changes.

Goal: Turn a fixed-date commitment into a bounded bet with scope that can be cut safely.
Paste in: the problem and its evidence, the fixed date, the team and any constraints from security, compliance or customers.

Help me shape a bet for [problem] that must ship by [date] with [team].

1. Propose an appetite (small batch of 1 to 2 weeks, or one or more six-week cycles) and explain why.
2. Describe the solution at sketch level: the main elements and how they connect, without detailed design.
3. List the rabbit holes most likely to blow the appetite, and how to avoid each.
4. List explicit no-gos.
5. Propose a circuit breaker: the reduced scope that ships if the full scope isn't ready, and the date we decide.
6. Name the outcome signal and when we'll check it.

Be ruthless about scope. Assume the date can't move.

Check the output: show the no-gos and the circuit breaker to the stakeholders who care about the date before the cycle starts. If they won't accept the reduced scope, the appetite is wrong, not the team.

Anti-patterns

Checklist

• The product’s North Star and quarterly outcome goals are written down and shared by every team.
• Each team’s work has been classified (planned vs unplanned, ordered vs complex) from real tracker data.
• Each team has a chosen method with a one-paragraph rationale and a trigger for revisiting it.
• Each team has a working agreement covering cadence, WIP limits, Definition of Done, agent use, interrupt handling and decision rights.
• The Definition of Done for AI features includes evals and a cost-per-task check.
• Every team reports WIP, throughput, work item age and cycle time, including age in review and verification states.
• Interrupt work has classes of service and a published SLE that customer-facing teams can quote.
• Every fixed-date commitment has an appetite, explicit no-gos and a circuit breaker agreed in advance.
• The RICE sheet uses one reach unit suited to B2B, evidence labels on confidence and full effort to production.
• Items with deadlines or rising costs have been re-scored with cost of delay, and every override is recorded with its reason.
• Sprint or cycle reviews include customer evidence and end with decisions.
• The discovery track kills or reshapes ideas before they reach the delivery backlog.
• A process health check runs every quarter, with at most two changes chosen.
• Before any scaled framework is adopted, dependencies that architecture could remove have been listed.