Purpose: Reference document for the Scrum → Kanban transition.
Audience: All members of the Razzmatazz team.
Effective: Starting the week of the transition.
We are moving from 3-week Scrum sprints to Kanban to better align with our new release schedule:
Month 1 → EA1 (Early Access 1)
Month 2 → EA2 (Early Access 2)
Month 3 → GA (General Availability)
Scrum sprints are time-boxed and optimized for short, repeated delivery cycles. Kanban is flow-based and optimized for continuous delivery toward milestone gates — which matches our 3-month rhythm better. Work flows continuously; releases are cuts from whatever is done, not sprint deliverables.
The core mindset shift:
Stop asking "what can we finish this sprint?" and start asking "how do we keep work moving smoothly through the system?"
| Meeting | Reason |
|---|---|
| Sprint Planning | No sprints — replaced by Replenishment Meeting |
| Sprint Review / Demo | Replaced by milestone-based demos at EA1, EA2, GA |
| Sprint Retrospective (on sprint cadence) | Replaced by time-based retrospective (every 4 weeks) |
| Meeting | Change |
|---|---|
| Daily Standup | Keep, but change the format (see below) |
| Meeting | Purpose | Cadence | Duration |
|---|---|---|---|
| Replenishment Meeting | Pull groomed tickets from Backlog into Ready | Weekly | 30 min |
| Flow Review | Review cycle time, WIP, blockers — is the system healthy? | Bi-weekly | 30 min |
| Milestone Planning | Align on target scope for each phase (EA1/EA2/GA) | Start of each phase | 60 min |
| Retrospective (time-based) | Reflect and improve — decoupled from sprint end | Every 4 weeks | 60 min |
Format: Walk the board right to left — from Done toward Backlog.
Focus on flow, not individual status reports.
Questions to ask at each column:
- Is anything blocked or stalled here?
- Is this column at or near its WIP limit?
- Does anyone need help moving a ticket forward?
NOT the goal:
- "What did I do yesterday / what will I do today"
- Individual status reporting
Rule: If a ticket has not moved in 2+ days, it must be flagged and discussed.
Purpose: Refill the Ready column so engineers always have prioritized, groomed work to pull from.
Agenda:
1. Review current Ready column — is it empty or almost empty? (5 min)
2. Review top of Backlog — are these tickets ready to pull? (15 min)
- Apply the Ticket Readiness Checklist (see Section 5)
- Send back anything that fails the checklist
3. PM confirms priority order of Ready column (5 min)
4. Confirm WIP is not already too high before pulling more work in (5 min)
Output: Ready column has 5–8 groomed, prioritized tickets the team can pull from.
Purpose: Inspect the health of the system, not just the output.
Agenda:
1. Throughput review — how many tickets completed this week vs last week? (5 min)
2. Cycle time review — what was the average? any outliers? why? (10 min)
3. WIP Age check — any tickets stuck in a column too long? (5 min)
4. Blocker retrospective — what blocked us? is it systemic? (5 min)
5. One process change to try before the next review (5 min)
Purpose: Align on what should be done by EA1, EA2, and GA. This is a target, not a commitment.
Agenda:
1. Review remaining backlog and in-flight work (15 min)
2. PM presents priority and business goals for this phase (10 min)
3. Feature leads identify which tickets should be tagged for this phase (20 min)
4. Tech lead flags any cross-feature technical risks (10 min)
5. Capacity check — does the volume match the team's realistic throughput? (5 min)
Output: Tickets tagged with the correct Target Release field (EA1 / EA2 / GA / Future).
Purpose: Reflect on process, team health, and continuous improvement.
Agenda:
1. What went well? (10 min)
2. What did not go well? (10 min)
3. Review metrics from the past 4 weeks:
- Throughput trend
- Cycle time distribution
- Carry-over count
- Blocker patterns
(15 min)
4. Identify 1–2 concrete process changes to try (15 min)
5. Check in on previous action items — did we follow through? (10 min)
Purpose: Measure success and learn from the phase.
Agenda:
1. Throughput trend — were we consistent week-over-week? (5 min)
2. Cycle time distribution — what was typical, any outliers and why? (10 min)
3. Carry-over count — what didn't make the phase? was it scope creep or a flow problem? (10 min)
4. Defect rate — bugs found in this phase vs carried from previous phase (10 min)
5. One process change to try next phase (10 min)
Switch from a Scrum board to a Kanban board. This removes sprint management and provides a continuous column view.
Backlog → Ready → In Progress → In Review → In QA → Done
| Column | Description |
|---|---|
| Backlog | Unrefined, unprioritized — work not yet ready to pull |
| Ready | Groomed, prioritized, passes readiness checklist — can be pulled anytime |
| In Progress | Actively being worked on |
| In Review | PR is open, awaiting code review |
| In QA | Under QA verification (Cypress tests, cluster verification) |
| Done | Merged and shipped |
WIP limits are mandatory. When a column is full, stop starting new work and swarm to unblock the full column.
| Column | WIP Limit (suggested, ~5-person team) |
|---|---|
| In Progress | 1–2 per engineer (5–8 total) |
| In Review | 4–6 |
| In QA | 4–6 |
Rule: A full column means the team helps unblock, not starts new work.
| Change | Details |
|---|---|
| Remove | Sprint field from all tickets |
| Add | Target Release field: EA1 / EA2 / GA / Future |
| Keep | Priority field — this controls pull order in the Ready column |
Each ticket should represent 1–3 days of active work — small enough to flow through the board without stalling, large enough to represent meaningful, reviewable work.
- One engineer can own it start to finish
- Acceptance criteria fit in 3–5 bullet points
- PR is reviewable in one sitting (~30–60 min)
- Can be described in one sentence
- Test plan is clear (what unit tests, what Cypress mock tests)
- More than 8 acceptance criteria
- Touches 5+ unrelated files or areas
- "It depends on how deep we go" — scope is undefined
- Estimated at more than 3 days
- PR will require multiple reviewers from different domains
Action: Split it before it enters Ready.
- A single function or CSS change with no broader context
- No acceptance criteria a QA engineer can verify
- Would take longer to write than to do
Action: Absorb it into a related ticket.
| Technique | Example |
|---|---|
| By user-facing behavior (preferred) | "List page (read-only)" → "Create form" → "Edit/Delete actions" |
| By layer | "BFF endpoint (Go)" → "Wire UI to BFF" |
| By happy path vs edge cases | "Create resource — happy path" → "Create resource — validation errors" |
| By data state | "Empty state" → "Loading state" → "Error state" |
Do not split by file ("update types.ts" is not a ticket), or in a way that makes one ticket dependent on another unfinished ticket.
Before a ticket moves from Backlog → Ready, it must pass:
□ Can be described in one sentence
□ Has 3–5 clear acceptance criteria
□ Can be owned by any engineer (no tribal knowledge required)
□ Estimated to complete in 1–3 days
□ Not blocked by another unfinished ticket
□ Test plan is clear (unit tests + mock Cypress tests)
□ Design and UX questions are resolved (or explicitly out of scope)
If a ticket fails more than 2 of these, it goes back to Backlog for more refinement.
Engineers pull the next ticket from Ready when they finish one. Work is never assigned from outside. The Ready column's priority order (set by PM/Feature Lead) determines what gets picked up next.
If "In Review" is at its limit, stop starting new work and help review. The value of WIP limits comes from honoring them under pressure, not just when it's easy.
A blocked ticket should be flagged the moment it is blocked — Jira flag + callout at standup. Do not sit on a blocker for a day hoping it resolves itself. Blockers are the primary enemy of flow.
Tickets that miss a phase gate (EA1, EA2, GA) and get re-tagged are carry-over. High carry-over means the phase was overloaded or the flow broke down. Track it and address the root cause, not just the symptom.
If cycle time is consistently over 5 days, tickets are too large. If it is consistently under 1 day, tickets may be too small. Aim for a tight cluster around 2–3 days. High variance means unpredictability — find and fix the cause.
100% busy does not equal healthy. Engineers need some slack to swarm on blocked tickets, help with reviews, and do exploratory work. A team running at 100% utilization cannot respond to blockers without stalling the whole board.
| Frequency | Metric | What It Tells You |
|---|---|---|
| Daily (standup) | WIP Age | Are tickets stalling right now? |
| Weekly (flow review) | Throughput | Is output consistent week-over-week? |
| Weekly (flow review) | Blocker count | How often does work stop and why? |
| End of phase | Cycle time distribution | How long does typical work take? Any outliers? |
| End of phase | Carry-over count | Did we scope phases correctly? |
| End of phase | Defect rate | How much rework are we creating? |
| End of phase | Target vs delivered | % of phase-tagged tickets actually completed |
| Metric | Why |
|---|---|
| Story points / velocity | Irrelevant without sprints |
| Individual throughput | Kanban measures team flow, not individual output |
| Utilization rate | 100% busy is not a goal |
Owns a specific feature or initiative from start to shipped. A temporary role worn for the duration of one feature.
Key responsibilities:
- Single point of contact for their feature across PM, UX, QA, and engineering
- Breaks the epic into right-sized tickets and keeps them unblocked
- Makes day-to-day scoping decisions ("does this go in EA1 or carry to EA2?")
- Watches WIP on their feature's tickets and escalates early if something is stalling
- Writes or reviews the test plan for the feature
Owns technical quality and architecture across the whole team. A permanent role spanning all features.
Key responsibilities:
- Sets and enforces technical standards (conventions, testing, security)
- Makes or facilitates major architectural decisions
- Reviews technically risky PRs and flags design concerns early
- Manages technical debt — knows where it is, decides when to address it
- Identifies cross-feature technical risks before they become blockers
- Escalation point when engineers disagree on technical approach
Owns the people and the environment they work in. Operates largely outside the code.
Key responsibilities:
- Hiring, onboarding, performance reviews, career development
- 1:1s to understand each person's growth, blockers, and satisfaction
- Removes organizational blockers (process, resourcing, cross-team politics)
- Capacity planning — who is available, who is overloaded, when to hire
- Represents the team upward to leadership and product management
| Situation | Owner |
|---|---|
| Architectural smell in a PR | Tech Lead |
| Ticket stuck in review for 4 days | Feature Lead |
| Engineer seems disengaged | Manager |
| Should we split this into two packages? | Tech Lead |
| Is this EA1 scope realistic? | Feature Lead + Manager |
| We need more engineers on this feature | Manager (with input from Feature Lead) |
Morning Standup (15 min)
Walk the board right to left (Done → In QA → In Review → In Progress)
Flag anything blocked or stalled
Anyone with open capacity pulls the next Ready item
During the Day
Work your ticket, update Jira column as it moves
If you are blocked, flag immediately — do not wait
Keep ticket descriptions and comments current
When You Finish a Ticket
Move to In Review, open PR
Pull the next highest-priority item from Ready
If In Review is at WIP limit — help review instead of starting new work
Weekly Replenishment (~30 min)
Pull groomed tickets from Backlog → Ready
PM confirms priority order
Apply readiness checklist to anything being promoted
Weekly Flow Review (~30 min)
Review throughput, cycle time, WIP age, blockers
Agree on one process change to try
Use this list to track readiness for the first week of Kanban:
□ Create Kanban board in Jira (replace Scrum board)
□ Design columns: Backlog / Ready / In Progress / In Review / In QA / Done
□ Set WIP limits on In Progress, In Review, In QA
□ Remove Sprint field from tickets; add Target Release field (EA1 / EA2 / GA / Future)
□ Priority-order the existing backlog; tag known EA1 targets
□ Cancel sprint planning, sprint review, and sprint retrospective calendar events
□ Schedule weekly Replenishment Meeting (30 min)
□ Schedule bi-weekly Flow Review (30 min)
□ Schedule Milestone Planning for EA1 kickoff (60 min)
□ Schedule Retrospective every 4 weeks (60 min)
□ Brief the team on the new standup format (walk board right to left)
□ Agree on WIP limit policy as a team (full column = swarm, don't start new work)
□ Enable cycle time tracking in Jira Kanban board reports
□ Share this document with the team and answer questions before week one begins
Document owner: Razzmatazz Team
Last updated: April 2026