A high-performance work system for experienced teams who value outcomes over ceremonies.

Scrumban Framework

Scope of the Framework

• The framework is intended for experienced development teams.

• It works best where the team can independently make operational decisions.

• It requires openness about blockers, overload, and flow quality.

• Less mature teams may require stronger managerial or leadership coordination.

Opening Principle

The way of working is treated as a system that can and should be changed. When signals of problems in workflow or team health appear, the first step is to analyze and improve the system rather than blame individuals.

Desired outcomes:

• Deep work protection

• Less context switching

• Fewer unplanned tasks and interruptions

• Clear rules for when not to start new work

• No estimation in story points

• Fewer meetings, more meaningful work

• Human-AI teamwork

• System improvement over individual blame

1. Board and Two Work Streams

1.1 Columns

Recommended board structure:

• Shape – clarify what will be done, why, and how the result will be verified.

• Build – implementation: code, configuration, infrastructure.

• Prove – testing and collecting evidence that the solution works and does not introduce errors.

• Ship – deployment, communication of the change, and monitoring of deployment effects.

• Done – task delivered, verified in production, and confirmed stable.
  The board structure may be adjusted depending on team needs.

1.2 Two Streams: Value and Value Rescue

Each task belongs to one of two streams:

• Value – planned product or technical work.

• Value Rescue – incidents, outages, hotfixes, urgent security issues.

A task can enter Value Rescue only if:

• It concerns real or imminent risk to users, security, revenue, or availability.

• Delaying the fix directly increases that risk.

• Note: This stream is not intended for “important features needed tomorrow”.

2. Single Task

2.1 Value Intent (two sentences)

Each task contains:

• Purpose – what effect, problem, or risk it addresses.

• How we know it works – 1–2 pieces of concrete evidence (test, report, observable change).

• Without Intent, a task cannot enter Build.

Recommended size:

A task should fit within a maximum of 4 days of work in the system. If larger, it should be split into smaller tasks with separate Intent.

2.2 One Owner + One Thread

Each task has:

• One owner responsible for ensuring completion, coordinating help, and communicating blockers.

• One thread or link containing the full history: decisions, agreements, Exit Evidence.

• Minimize the number of places where discussion occurs.

2.3 Exit Evidence

Moving to the next column requires proof that the work has been completed.

• Build → Prove: pull request, unit/integration tests executed, description of changes.

• Prove → Ship: test results, logs from trial deployments, confirmed rollback plan and monitoring.

• Ship → Done: Running in production, verified, no issues requiring action.

• No evidence means the task stays where it is.

3. System Limits: AVL, VRL, Age Limit

3.1 AVL – Active Value Limit

AVL defines the maximum number of active tasks in a column within the Value stream.

• AVL is defined separately for Shape, Build, Prove, Ship.

• Recommended starting point: Build = number of developers / 2 (rounded down).

• If AVL is full, no new work starts. Available people should help finish tasks in Prove/Ship or remove blockers.

3.2 VRL – Value Rescue Limit

VRL defines how many Value Rescue tasks can be active simultaneously.

• Typical value: 1–2 tasks.

• In critical incidents, VRL may be temporarily exceeded, but once under control, the limit is restored and reviewed during Tune.

• When VRL is full, a new incident requires a decision to pause a current task or temporarily exceed the limit.

3.3 Age Limit + Stop & Fix

Instead of estimating time, focus on how long a task remains in a column.

• Example limits: Shape (2 days), Build (4 days), Prove (2 days), Ship (2 days).

• Rule: Every Age breach triggers Stop & Fix.

• The task is discussed at the nearest Unblock meeting. The team selects actions like splitting the task, reducing scope, or adding support.

• Frequent breaches in the same column must be discussed during Tune.

4. People: Load Guard and Team Health

4.1 Load Guard (Green / Yellow / Red)

• Green – acceptable to take on new work.

• Yellow – close to limit; priority is finishing active tasks.

• Red – overload; new tasks should not be started.

• Agreements: Load Guard must not be used for evaluations. If used for control, the system loses its primary signal source.

• When many members are Yellow/Red, AVL should not be filled, meetings should be reduced, and focus shifts to closing tasks.

4.2 Team Health

Once per week the team reviews: Energy, Focus, Pressure, Clarity.

• Each person states: better (+), same (0), or worse (-) than last week.

• If the majority reports “worse” in 2+ areas, the topic is automatically brought to Tune to adjust the system.

5. Decision Gates

5.1 Start Gate (Shape → Build)

A task enters Build only when: Intent is clear, there is capacity in Build, and evidence for Build → Prove is known.

5.2 Ship Gate (Prove → Ship)

A task enters Ship only when: tests are completed, a rollback plan exists, and impact has been assessed.

6. Work Rhythm

• 6.1 Select (15 min, 2x/week): "Can the system accept new work?" Review AVL, Age, Load, and Health.

• 6.2 Unblock (10–15 min daily): "What is blocking flow today?" Review board right-to-left. Focus on Age breaches and blockers.

• 6.3 Tune (25 min, 1x/week): "What system changes do we need?" Review metrics and Health. Select one specific change to test for a week.

• 6.4 Hangout (30 min, 1x/week): No agenda. Casual conversation/social time.

7. Metrics

Analyzed as trends, not single numbers:

• Finish Rate (tasks/week)

• Active Value (concurrent tasks)

• Age Breaches (limit violations)

• Value Rescue Share (incident capacity)

• Ping-pong count (Build ↔ Prove returns)

8. When Value Rescue Dominates

If Value Rescue consumes most energy for several weeks, during Tune the team should:

• Temporarily limit new product initiatives.

• Plan tasks focused on stabilization and root cause reduction.

• Communicate: “For the next X weeks we are investing in stability.”

9. AI in Team Work

AI is a tool, not a decision-maker. Work produced with AI requires human ownership and verification.

• 9.1 Rules: Human Owner, Verification Evidence, and Traceability (short note on AI usage).

• 9.2 Classification: NONE (no AI), ASSIST (human-driven), CORE (AI-generated).

• 9.3 Verification: AI output must have automated tests, manual review, or reproducible execution before moving.

• 9.5 AI Gain: Observed via Age Breaches, Ping-pong, and Finish Rate. If rework increases, AI usage is adjusted.

10. Recommendations

1. New work should not start when AVL is full.

2. Tasks do not move without Exit Evidence.

3. Red status or Age breaches must never be ignored.
   All other numbers and rules can be adjusted if these three remain intact.

11. Closing

Scrumban reminds us: do not attach yourself to the form — attach yourself to responsibility. Change the rules when they stop serving people and value. Build systems that help deliver value without harming people, relationships, or the environment.