Skip to Content
DocsFlowTeam Kanban Flow
DRAFT — This document is under development and not yet reviewed.

Team Kanban Flow

The team’s delivery system operates at the iteration level. Stories flow from the Product Backlog through a sprint cycle to done — integrated, tested, and potentially releasable at the end of every iteration.

The team’s flow is not isolated. It is the execution layer that makes feature delivery possible. What the team ships in each sprint is the building block of every feature the DVS commits to delivering.

Flow Stages

1. Product Backlog

All candidate stories for the team — derived from features in the DVS backlog, plus technical debt items, bug fixes, and refinement outcomes. The Product Backlog is not a queue to work through sequentially. It is a prioritized pool.

Entry: Any work item identified as a potential team-level delivery, derived from a Feature or identified independently.

Exit: The story meets the Definition of Ready and is selected for an upcoming sprint.

2. Refinement

Stories are analyzed, clarified, and prepared for sprint selection. Refinement is continuous — not a single event — and ensures the top of the backlog is always ready to be pulled.

Work in this stage:

  • Clarify acceptance criteria with the Product Owner
  • Break down stories too large to complete in one sprint
  • Identify and surface dependencies
  • Estimate complexity or size as needed

A story that enters a sprint unprepared creates drag for the whole team. Refinement is the investment that prevents this.

Exit: Story meets the Definition of Ready — clear, sized, acceptance criteria defined, dependencies identified.

3. Sprint Backlog

Stories selected for the current sprint. The sprint goal frames what the team is trying to achieve — individual stories are in service of that goal, not independent items to tick off.

The sprint backlog is the team’s commitment. WIP limits within the sprint — often implicit in team capacity — prevent overcommitment.

Exit: Work begins (moves to In Progress).

4. In Progress

Active development. In a modern delivery team, “in progress” covers the full engineering cycle: design, implementation, automated testing, security review, and integration — not just coding.

Principles for healthy flow here:

  • One story at a time per developer where possible — task switching is waste
  • Continuous integration: integrate to the main branch at least daily
  • Tests written alongside or before code (shift-left quality)
  • The story is not done until it passes the pipeline — not until the developer believes it is done

WIP should be explicitly limited. Stories that sit In Progress for multiple days without movement are a signal worth investigating.

Exit: Implementation complete, automated tests pass, code reviewed and merged.

5. Verification

The story is verified against its acceptance criteria. In a mature team, the majority of verification is automated and embedded in the pipeline. Manual exploratory testing addresses what automation cannot reach.

This stage is not a handoff to a separate QA function. The team owns quality — verification is part of the team’s definition of done, not a downstream gate.

Exit: Acceptance criteria met, no known blockers to integration.

6. Done

The story is complete — integrated, tested, and part of the product increment. It contributes to a potentially releasable increment at the end of the sprint.

Done has a precise meaning defined by the team’s Definition of Done. Common elements:

  • Code reviewed and merged
  • Automated tests passing (unit, integration, relevant end-to-end)
  • Feature flag or release mechanism in place if not immediately released
  • Observable in production monitoring if applicable
  • Documentation updated if relevant

A story is not done until it meets the DoD. Partial credit does not exist.

Definition of Ready

A story is ready to enter a sprint when:

  • The acceptance criteria are clear and testable
  • The story is sized to be completable within one sprint
  • Dependencies are identified and either resolved or explicitly accepted
  • The team has sufficient shared understanding to begin without re-asking the Product Owner

Definition of Done

Done means the increment is potentially releasable. Each team defines their own DoD, calibrated to their technical context and organizational release standards. The DoD is a living agreement — it should become more demanding as the team’s capability matures.

Flow Visualization

In Progress and Verification have WIP limits.

DVS Improvement FlowOverview