- SAP Managed Tags
A lot of the AI conversation right now is about headcount. How many people can we cut? Which roles become redundant? We built something with the opposite goal. We wanted our PO to run better refinements. We wanted our developers to spend their energy on code, not on reconstructing context from half-filled tickets. We wanted our QA engineers to test with precision instead of guessing from vague descriptions. And we wanted our Scrum Master to facilitate a team that was actually well-prepared — not one that spent half of every planning session re-explaining decisions made two weeks ago.
So we built a pipeline. Not to replace anyone — to give every role on the team a better version of the work they were already doing.
Our Scrum Process
Our process worked. We had the ceremonies, the rituals, the tools. But there was a tax on every stage that nobody talked about because nobody knew how to fix it.
The PO finished the pre-refinement meeting and then sat down to write up Jira from memory. The Scrum Master ran refinement with a team that had partly forgotten what was discussed two weeks ago. The developer picked up a ticket and found two lines of description — and spent the next hour piecing context together from chat history and old meeting recordings. QA sat down to test a feature and rewrote the acceptance criteria into a test checklist from scratch, because that's the only way to make them actionable. And when scope changed mid-sprint, someone manually updated four subtasks to match.
None of this was a failure. It's just what happens when information moves faster than anyone can write it down. The pipeline captures that information automatically — at each stage, for each role — so it's there when the next person needs it.
The Manual Tax — Before & After
Pain points:
- UX-dev disconnect — feasibility issues found late in refinement
- Context loss — pre-refinement decisions re-discussed in refinement
- Inconsistent ticket quality — some detailed, others vague
- Oversized tasks — large PRs that are hard to review
- Manual subtask creation — descriptions truncated, dependency links never maintained
- Mid-sprint changes — no structured way to propagate AC changes to subtasks
The cost:
- Refinement wastes time catching up on pre-refinement context
- Devs spend hours writing prompts to explain business context or build guidance
- Sprint planning runs over time on task sizing
- PR descriptions and sizes vary wildly — reviewers waste time orienting
- QA infers test scenarios from incomplete ticket descriptions — no explicit checklist
What changed:
- Pre-refinement context is written down — refinement starts informed, not from scratch
- Enriched tickets provide business context and build guidance — devs don't spend hours writing prompts
- Stories pre-decomposed into PR-sized tasks — sprint planning sizes work in minutes, not hours
- Tasks define PR scope upfront — consistent size and standardised descriptions for reviewers
- QA receives a checklist grounded in complete, consistent ACs and actual merged code
- Mid-sprint AC changes propagate automatically to affected subtasks
Design Principles
- AI as accelerator — AI reduces effort, never replaces judgment. Every output is a draft for a human to review and approve.
- Human approval at every gate — No auto-merges, no auto-created tickets, no auto-approved tests. The human stays in the loop at every handoff.
- Claude Code as integration backbone — Custom skills are the delivery mechanism at every stage — planning, development, code review, QA. One consistent interface across the whole pipeline.
- Structured process through skills — Every stage has a defined skill and agent with clear, predictable output. No ad-hoc prompting, no freestyle context dumps.
- Upstream investment pays off downstream — Better refinement → better user stories → better tasks → better code → faster reviews → structured QA → better quality overall.
Sprint Stages
🎙️ Pre-Refinement → 🔍 Refinement → 📋 Sprint Planning → 💻 Development → 👁️ Code Review → 🧪 QA & Testing → 🎤 Sprint Review → 🔄 Retrospective
- Pre-Refinement — PO + 1–2 devs discuss upcoming tickets. Early feasibility checks, initial AC drafts, design alignment. AI layer: /prepare-ticket
- Refinement — Full team finalises ACs, clarifies technical details, assigns estimates. AI layer: /enrich-ticket → /adjust-ticket
- Sprint Planning — Refined tickets committed to sprint, broken into tasks. AI layer: /decompose-ticket
- Development — Developers pick up tasks and implement. AI layer: /pull-next-task → /create-pr
- Code Review — Peers review PRs; review bot weights findings by file criticality. AI layer: PR bot + heat map
- QA & Testing — Testers validate against ACs; findings loop back as Jira sub-tasks. AI layer: /qa-analysis → /qa-analysis-report
- Sprint Review — Team demonstrates completed work to stakeholders. Human conversation only.
- Retrospective — Team reflects on the sprint. Human conversation only.
The Pipeline
The pipeline is the answer to the manual tax. Each stage runs as a Claude Code skill — a slash command that knows the full context of the sprint ceremony it belongs to. The result is a checklist that completes itself: transcript segmented, ticket prepared, enriched, decomposed, implemented, reviewed, and QA-analysed — with zero manual Jira edits and zero prompts typed by the team beyond invoking the skill.
Every stage produces a structured artefact that's automatically attached to the Jira ticket. Open any ticket and the full paper trail is there: what was discussed, what was decided, how it was broken down, and what the QA findings were.
🎙️ Segment Transcript → 📝 Pre-Refinement Prep → 🔍 Enrichment → ✏️ Ticket Update → 📋 Decomposition → 🎯 Task Pickup → 💻 PR Creation → 🧪 QA Analysis
Demo Video
A Real Example — End to End
Before we walk through how each stage works, here's what the full pipeline looks like in practice. One of our user stories — letting users export a data table to CSV — went from refinement meeting to QA sign-off without a single manual Jira edit and without a single ad-hoc prompt typed to Claude. Not a single field updated by hand. Not a single free-form question asked to the AI. Every step was a slash command. Here is what happened.
The ticket
Users wanted to export the contents of a data table to a CSV file. The backend already had a data-access layer; the export just needed a new endpoint and a download button wired to it. Clear scope, reference patterns already in the codebase. Simple on paper — but in previous sprints a ticket like this would have arrived at development with a two-line description and nothing else.
Step 1 — Before the refinement meeting
/prepare-ticket scanned the codebase before the meeting and produced a preparation document. It found where the existing data-access pattern lived, identified which layers would need to change, and flagged an edge case the ticket hadn't mentioned: what should the file be named — a static filename, or should it include the current date and the active filters? The team walked into the refinement meeting with that question already on the table.
Step 2 — After the refinement meeting
After the meeting, /enrich-ticket merged the preparation document with the refinement transcript. Every decision the team made was captured with its source and timestamp — including one that changed from a tentative assumption to a confirmed decision during the discussion:
[DECISION] Export includes all columns currently visible — hidden columns are excluded.
Source: refinement, ~03:17
[DECISION] Filename includes the export date and a short label, e.g. "items-2025-06-01.csv".
Source: refinement, ~07:44–08:22
[DECISION] Large exports (over 10 000 rows) show a loading indicator; no pagination.
Source: refinement, ~12:05–13:10
[REVISED] The export button lives in the table toolbar, not the page header.
Was: TENTATIVE — position not confirmed, page header suggested.
[OPEN] Should filtered-out rows be included in the export or excluded?
Discussed but not conclusively resolved. [BLOCKING]Step 3 — Jira ticket updated
/adjust-ticket showed a section-by-section diff of what would change in the Jira ticket. After the team approved it, it wrote the structured content back — the Why, the Acceptance Criteria, the Technical Details — all from the enrichment document. Nobody opened Jira.
Step 4 — A change arrives mid-sprint
After sprint planning, the PO added a new requirement: the export feature had to be hidden behind a feature flag until it was ready to roll out to all customers. /adjust-ticket detected the change. /adjust-tasks then read the existing subtask and propagated the impact — adding the flag guard, updating the relevant file entries, and producing a changelog that made the scope of the change visible at a glance:
## Changes Detected in Parent Ticket
[NEW] Technical: export button must be hidden behind a feature flag; "csv-export"
## Subtasks Affected
Task 1: Add CSV export to the data table
Action: Updated
Reason: Feature flag requirement added; button component updated, template guard added,
2 new flag-state tests added, existing tests updated to mock flag serviceStep 5 — Decomposition
/decompose-ticket read the enrichment document and scanned the actual codebase. It determined that all the changes were tightly coupled and correctly recommended a single PR. It listed every file to touch, what to change in each, what tests to write — and flagged a pre-existing type inconsistency in the data layer that the team should be aware of but leave out of scope for this ticket.
Step 6 — Developer picks up the task
/pull-next-task showed the status dashboard for the story, assigned the task in Jira, created the branch, and dropped the developer straight into plan mode — with the enriched Jira ticket and the full decomposition already loaded as context. No prompt typed. No context explained. Five stages of preparation delivered in one command. The developer had the exact file list, the test cases, the edge cases, and the feature flag requirement all in one place before writing a single line of code.
Step 7 — PR created
After implementation, /create-pr wrote the PR description from the commits and diff. The developer didn't write a word of it:
## Why Add a CSV export button to the data table toolbar, behind a feature flag, so users can download the currently visible rows. Also fixes a type inconsistency in the data layer. ## What - Export button rendered in the toolbar when the feature flag is enabled - Export service calls the existing data-access layer and streams the response - Filename generated dynamically from the export date and table label - Stale type alias removed from the data layer ## Changes to Review ### Critical - export.service.ts — new export method, streams CSV response - table-toolbar.component.ts — export button wired to service ### Medium - app.module.ts — ExportService registered - table-toolbar.component.html — button and loading indicator added - table-toolbar.component.spec.ts — tests for flag-on / flag-off states ### Low - data.types.ts — stale type alias removed - export.service.spec.ts — unit tests for filename generation and row filtering
Step 8 — QA analysis
After the PR merged, /qa-analysis produced a QA report without anyone writing a brief. It cross-referenced what was built against what was planned, mapped every acceptance criterion to the PR that covered it, and generated step-by-step test scenarios for each one — including the navigation path, the pre-conditions, and the expected result:
AC3: The exported file contains only the columns currently visible in the table. Given a user on the data table page with the feature flag enabled When they hide the "Created By" column and click Export Then the downloaded CSV does not contain a "Created By" column Steps: - Navigate to the data table page - Open column settings and hide "Created By" - Click the Export button in the toolbar - Open the downloaded file - Verify "Created By" column is absent and all visible columns are present
Step 9 — QA report walkthrough
The tester ran /qa-analysis-report and worked through each scenario. Six out of seven acceptance criteria passed. AC3 failed — the export button was visible but the downloaded file always contained all columns regardless of visibility settings. The skill created a Jira sub-task for the defect without the tester touching Jira:
AC1 ✅ PASS — Export button visible when feature flag is enabled AC2 ✅ PASS — Export button hidden when feature flag is disabled AC3 ❌ FAIL — Downloaded CSV contained all columns; visible-column filter ignored AC4 ✅ PASS — Filename includes export date and table label AC5 ✅ PASS — Loading indicator shown during export AC6 ✅ PASS — Empty table exports a header-only CSV, no error AC7 ✅ PASS — Export works correctly with active row filters applied Defect created: QA: CSV export ignores column visibility settings Jira sub-task created automatically under the parent story
0 manual Jira edits. 0 ad-hoc prompts to Claude. 9 pipeline stages completed.
From refinement meeting to QA sign-off — every decision captured, every file identified, every test specified, every Jira field updated, every defect tracked. The pipeline ran. The team reviewed and approved at each gate.
The rest of this post walks through each stage in detail — what gap it fills, how it works, and what the output looks like.
Stage 1 — Transcript Segmentation
The gap: Our pre-refinement and refinement meetings cover multiple tickets in one session. The raw transcript is one long file — you can't hand that to an AI and say "prepare ticket PROJ-1042" without giving it everything else too.
The first thing we built was /segment-transcript. You give it a transcript file and a list of ticket IDs; a transcript-segmenter agent reads the full text and writes one segment file per ticket, preserving the original wording verbatim. It handles German and mixed German/English transcripts natively — no translation step, no preprocessing.
This became the foundation for everything else. Both pre-refinement preparation and refinement enrichment start from these segment files. Same input, two downstream consumers.
Benefit: Every downstream skill gets exactly the transcript context it needs — nothing more, nothing less.
Stage 2 — Pre-Refinement Preparation
The gap: Pre-refinement discussions are where a lot of early thinking happens — feasibility questions, initial AC drafts, tentative decisions. Not all of it made it cleanly into the ticket before the full refinement meeting.
/prepare-ticket takes the transcript segment for a ticket and produces a structured preparation document: a decision log with speaker attribution, draft acceptance criteria tagged by source (ticket vs. transcript), technical details, open questions, and an effort estimate. Multiple tickets are processed in parallel — one ticket-preparer agent per ticket.
We added this first, before any other stage. A single skill that turned a meeting recording into something a developer could actually use before walking into refinement. The output format evolved over a few sprints as we learned what the team actually needed going into those meetings.
Example output:
# Pre-Refinement Preparation — PROJ-1042
> Ticket: Add CSV export to the data table
> Prepared from: Pre-refinement meeting transcript + Jira draft
> ⚠️ AI-prepared from pre-refinement — review before refinement meeting
## Decision Log
- [DECISION] Export should use the existing data-access layer — no new query needed.
— ~18:44
- [TENTATIVE] The export button will likely go in the table toolbar.
— ~19:52 — Confirm in refinement
## Draft Acceptance Criteria
AC1 [TICKET]
Given a user on the data table page,
When they click the Export button,
Then a CSV file is downloaded containing the visible rows.
AC2 [TRANSCRIPT]
Given hidden columns are present in the table,
When a user exports,
Then hidden columns are excluded from the CSV.
## Open Questions for Refinement
- [OPEN] Should filtered-out rows be included in the export or excluded?
— Reason: Not addressed in ticket or pre-refinement. [BLOCKING]Benefit: The team walks into refinement with decisions already surfaced, draft ACs ready to review, and open questions flagged before they become blockers.
Stage 3 — Refinement Enrichment
The gap: Refinement meetings often revisit and revise what was discussed in pre-refinement. A decision that seemed settled gets updated, an AC gets refined, a technical detail gets corrected. That evolution wasn't being captured.
/enrich-ticket merges the pre-refinement preparation document with the refinement transcript segment for the same ticket. Every item is source-tagged — [PRE-REFINEMENT] vs. [REFINEMENT] — and decisions that changed between the two meetings are surfaced as [REVISED]. The enrichment document becomes the single source of truth going into sprint planning.
The [REVISED] tag turned out to be one of the most valuable outputs. It makes explicit what changed and why — something that would otherwise live only in someone's memory.
Example output:
## Decision Log - [DECISION] Export includes only columns currently visible — hidden columns are excluded. — Source: pre-refinement, ~18:44 - [REVISED] The export button is placed in the table toolbar, not the page header. — Was: TENTATIVE — page header suggested in pre-refinement. — Source: refinement, ~07:12 - [DECISION] The existing data-access layer is reused — no new backend query needed. — Source: refinement ## Edge Cases - [EDGE CASE] What happens if the user exports while a sort or filter is active? Should the export reflect the current view or the full unfiltered dataset? — ~24:30
Benefit: Decisions that evolved between meetings are explicit. No more "wait, didn't we agree something different in pre-refinement?"
Stage 4 — Ticket Update
The gap: Having a beautiful enrichment document in a local markdown file doesn't help the developer who opens the Jira ticket. The ticket itself needed to be the source of truth.
/adjust-ticket fetches the current Jira ticket, merges it with the enrichment document into a fixed three-section format — Why?, Acceptance Criteria, Technical Details — and shows a section-by-section diff for review before writing anything to Jira. Nothing is updated without explicit approval.
The three-section format was a deliberate choice. Every ticket in the backlog now has the same structure. Developers know exactly where to look. The "Why?" section in particular changed how developers approached their work — they had context, not just requirements.
Benefit: Consistent, structured ticket quality across the entire backlog. The Jira ticket is the single source of truth, not a separate local file.
Stage 5 — Sprint Planning & Decomposition
The gap: "Implement PROJ-1042" is not a task. It's a wish. Developers need to know which files to touch, what tests to write, what depends on what — before they start, not while they're figuring it out.
/decompose-ticket reads the enrichment document and scans the actual codebase to produce a decomposition document: a set of tasks, each scoped to one small reviewable PR. Each task comes with a dependency graph, the specific files to change, what tests to write, and an AC coverage matrix. The codebase scan is what separates this from a generic task breakdown — the file paths are real, derived from the actual repo at that point in time.
Each file is labelled with a criticality level — Critical, Medium, or Low — based on its role in the change. That label travels downstream into the PR description and from there into the review bot's heat map.
Example output:
### Task 2: Wire export button to service and add feature flag guard
PR scope: table-feature
Depends on: Task 1
ACs covered: AC1, AC2, AC5
Why: The button and feature flag guard are UI concerns that belong in their
own PR so the service layer can be reviewed independently before the UI lands.
Files:
[Critical] src/app/table/table-toolbar.component.ts
— export button + feature flag signal
[Critical] src/app/table/table-toolbar.component.html
— button and loading indicator, guarded by flag
[Medium] src/app/table/table-toolbar.component.spec.ts
— tests for flag-on / flag-off states
Changes: Render the export button only when the feature flag is enabled.
Call ExportService.download() on click; show a loading indicator while
the request is in flight.
Tests:
- Unit: Button visible when flag enabled, hidden when disabled
- Unit: Loading indicator shown while export is pending
- Unit: Error state shown if export service returns an error
## AC Coverage Matrix
| AC | Task(s) | Status |
|-----|------------|---------|
| AC1 | Task 1, 2 | Covered |
| AC2 | Task 1 | Covered |
| AC3 | Task 1 | Covered |
| AC4 | Task 2 | Covered |
| AC5 | Task 2 | Covered |Benefit: Developers start with a map, not a blank page. File paths, test cases, and dependencies are pre-loaded before the first line of code is written.
Stage 6 — Task Pickup
The gap: Even with a good decomposition document, the jump from "task exists" to "developer is in the right context, on the right branch, with the right plan" involved too many manual steps.
/pull-next-task fetches all subtasks for a parent ticket, shows a status dashboard — Done, In Progress, Available, Blocked — resolves dependencies from Jira issue links, and lets the developer pick an available task. It then assigns the task in Jira, transitions it to In Progress, creates the git branch, and drops the developer into plan mode with the full task context pre-loaded.
The plan mode entry is where something important happens: the enriched ticket and the decomposition task together become the prompt. The developer doesn't type anything to Claude — the skill reads the Jira ticket, loads the decomposition, and selects the right Claude Code plugin automatically based on the task type (feature-dev for new feature work, superpowers for pipeline-adjacent tasks). The developer picks a task, approves the plan, and starts coding. No context dump. No "here's what the ticket says" preamble. The ticket is the specification. The decomposition is the implementation guide. The skill handles the rest.
This is also why there are zero ad-hoc prompts in the end-to-end example. There's nothing to prompt — the structure is already there. This was the moment the pipeline started feeling like a real system rather than a collection of scripts. Everything upstream had been building context. This step delivered it to the right person, in the right tool, at the right time. Developers stopped spending the first hour of a task reconstructing what had already been discussed in three separate meetings.
Benefit: Zero to focused development in one command. No branch setup, no Jira clicks, no context reconstruction, no ad-hoc prompting — the ticket is the prompt, and the skill selects the right plugin automatically.
Stage 7 — PR Creation & File Criticality Heat Map
The gap: PR descriptions varied wildly in quality. Some had great context; others were "fix stuff." Reviewers had no way to know which files deserved the most scrutiny.
/create-pr extracts the Jira ticket ID from the branch name, analyses the commits and diff, and creates a PR with a consistent structure: Why (the business reason), What (what changed), and Changes to Review split into three tiers — Critical, Medium, and Low — with file paths sourced directly from the decomposition document.
Those criticality labels aren't just cosmetic. The review bot is configured with a focused output format: it opens every review with a Review Matrix that cross-references file risk (taken directly from the PR description's Changes to Review section) against its own finding severity. The combination produces a clear priority for each finding — URGENT, HIGH, MEDIUM, LOW, or GLANCE.
The chain: decompose-ticket marks files Critical/Medium/Low → /create-pr embeds labels in PR description → PR review bot reads file risk from PR description and cross-references with finding severity → Review Matrix shows reviewer exactly where to focus.
Example PR description:
PROJ-1042: Add CSV export to the data table
## Why
Users had no way to download the data currently visible in the table. The backend
data-access layer already existed; this change adds an export service on top of it,
a feature-flagged toolbar button, and ensures the exported file reflects exactly
what the user sees — active column visibility and filters applied.
## What
- Added ExportService with streaming CSV download and dynamic filename generation
- Export button and loading indicator added to table toolbar, guarded by feature flag
- Stale type alias removed from data layer
- Unit tests cover filename generation, column filtering, and feature flag states
## Changes to Review
### 🔴 Critical
*Core business logic, auth/security, data model changes, cross-service communication.*
- src/app/export/export.service.ts
— streaming CSV response, column filtering logic
### 🟡 Medium
*New service methods, DTO changes, state management, new endpoints.*
- src/app/table/table-toolbar.component.ts
— feature flag signal, export button wired to service
- src/app/table/table-toolbar.component.html
— button and loading indicator, feature flag guard
### 🟢 Low
*Test additions, renaming, SCSS/template-only changes.*
- src/app/shared/data.types.ts
— stale type alias removed
- src/app/export/export.service.spec.ts
— unit tests for filename generation and column filtering
- src/app/table/table-toolbar.component.spec.ts
— tests for flag-on / flag-off statesAnd the resulting Review Matrix from the bot:
Review Matrix ⬛ URGENT 🔴 export.service.ts CSV stream not closed on error — partial file may be written to disk File Risk: 🔴 HIGH · Severity: 🔴 CRITICAL 🟥 HIGH 🔴 export.service.ts No timeout handling if data-access layer is slow to respond File Risk: 🔴 HIGH · Severity: 🟡 MEDIUM 🟧 MEDIUM 🟡 table-toolbar.component.spec.ts Loading indicator test does not assert dismissal after completion File Risk: 🟡 MEDIUM · Severity: 🟡 MEDIUM ⬜ GLANCE 🟢 data.types.ts Removed type alias was still referenced in one JSDoc comment File Risk: 🟢 LOW · Severity: 🟢 LOW
Detailed findings follow, grouped by priority — URGENT first, then HIGH, MEDIUM, LOW. A reviewer can triage in seconds.
Benefit: Every PR has the same structure and every reviewer knows exactly which files need the most attention — the decomposition's risk assessment flows all the way through to the automated review output.
Stage 8 — QA Analysis & Report
The gap: QA testing without structured input often meant re-reading the ticket, trying to infer what changed, and writing ad-hoc test steps. Coverage was uneven, and defects that didn't make it into Jira quickly got lost.
/qa-analysis cross-references merged PRs (via GitHub CLI), the Jira ticket (via Atlassian CLI), and the decomposition document to produce a QA analysis report per ticket. The output is a set of Gherkin-style test scenarios with exhaustive pre-conditions, exact navigation steps, and a classification of each scenario — UI Test, QA + Dev, or Dev-verified. It also flags AC coverage gaps and regression impact on adjacent features.
Once the tester has done their manual testing, /qa-analysis-report walks through each scenario interactively: pass, fail, or skip. Failed scenarios are automatically created as Jira sub-tasks under the story, prefixed with QA:. Those sub-tasks then flow back into the development cycle via /pull-next-task, closing the loop.
Example output:
#### AC2: The exported file contains only columns currently visible in the table Scenario: Hidden columns excluded from export Given a user on the data table page with the feature flag enabled And the "Created By" column is hidden in the column settings When the user clicks the Export button Then the downloaded CSV does not contain a "Created By" column And all currently visible columns are present with correct headers Detailed execution steps: - [ ] Navigate to the data table page - [ ] Open column settings and hide "Created By" - [ ] Click the Export button in the table toolbar - [ ] Open the downloaded CSV file - [ ] Verify "Created By" header is absent - [ ] Verify all other visible column headers are present and correctly named Where to verify: Table toolbar → Export → downloaded file Classification: UI Test
Benefit: Testers start with a focused, codebase-grounded checklist instead of re-reading the ticket. Defects flow directly back into Jira as sub-tasks, closing the loop automatically.
How to Bring Your Team Along
Introducing AI tooling into an existing team is less a technical problem than a trust problem. The approach that worked for us: go one skill at a time, start where the pain is most visible, and never automate a step without showing the output first.
Start with /segment-transcript alone — no downstream effects, just show the team what segments look like. Then add /prepare-ticket before a refinement meeting, share the doc, and let the team push back on what the AI got wrong. That calibration is the point — you want people to see the output is a draft, not a decision already made.
From there, enrich one ticket live as a workshop. Walk through the enrichment document as a team, suggest corrections, then run /adjust-ticket together. This is the moment trust gets built: the team sees that their words and decisions are preserved, not rewritten.
Decompose one story in sprint planning, adjust the task list live, give developers ownership over what gets created. Then let developers start using /pull-next-task individually — pair up the first few times. Standardise /create-pr once everyone's seen a few consistent PR descriptions. Introduce /qa-analysis only after a sprint closes, as a retrospective exercise — not during a live sprint.
The skills are independent — you don't have to adopt the full chain. Start with the stage where your team feels the most friction.
One principle held everything together
AI does the prep work and analysis. Humans make every decision.
No auto-merges. No tickets written without review. No Jira updates without a diff shown first. The pipeline produces output — the team approves it. That distinction matters, and it's why the team trusted it.
What surprised me most was how much the upstream stages paid off downstream. Better pre-refinement preparation meant the PO walked into refinement with a head start, not a blank slate. Tighter enrichment documents meant the Scrum Master could point at a single source of truth instead of moderating a "what did we agree?" debate. Cleaner decompositions meant developers opened a ticket and found a map, not a wish. That context produced PR descriptions reviewers could actually use. Those descriptions fed QA checklists that were grounded in what was actually built. The whole chain compounded — and every role on the team got a better version of their own work.
That's what we set out to build. Not a replacement. An amplifier.
If you'd like help adapting any of these skills to your team's process, reach out. Happy to answer questions in the comments.
Bluesky| User | Count |
|---|---|
| 27 | |
| 18 | |
| 12 | |
| 12 | |
| 6 | |
| 6 | |
| 6 | |
| 5 | |
| 4 | |
| 4 |
