Project Boards And Delivery Flow

The two dominant systems for organizing flow around a board are Scrum and Kanban. Most real teams run a blend, but the ingredients are worth knowing separately, because they solve different problems.

Scrum: Timeboxed Iterations

Scrum organizes work into sprints — fixed timeboxes, usually one to four weeks, in which the team commits to a slice of work and delivers a usable increment at the end. Three roles hold it together: the product owner owns the product backlog, the ordered list of everything the product might need, and decides what matters next; the developers build the increment; and the scrum master owns the process itself, removing blockers and keeping the ceremonies honest rather than managing people.

The ceremonies map to the sprint's lifecycle:

<?php

declare(strict_types=1);

$ceremonies = [
    'sprint planning' => 'select backlog items into the sprint and agree what done means',
    'daily standup' => 'fifteen minutes: progress, plan, and blockers - not status theater',
    'sprint review' => 'demonstrate the increment to stakeholders and gather feedback',
    'retrospective' => 'the team inspects its own process and picks one improvement',
];

foreach ($ceremonies as $ceremony => $purpose) {
    echo $ceremony . ': ' . $purpose . PHP_EOL;
}

// Prints:
// sprint planning: select backlog items into the sprint and agree what done means
// daily standup: fifteen minutes: progress, plan, and blockers - not status theater
// sprint review: demonstrate the increment to stakeholders and gather feedback
// retrospective: the team inspects its own process and picks one improvement

Scrum's measurements follow from the timebox. Velocity is how much backlog the team completes per sprint, useful for forecasting and dangerous as a performance target. A burndown chart shows remaining sprint work against time. Both are thermometers, not goals: a team that optimizes velocity numbers gets inflated estimates, not faster delivery.

Kanban: Continuous Flow

Kanban drops the timebox. Work flows continuously across the board, and the discipline comes from work-in-progress limits: each column has a maximum card count, and when a column is full, nobody starts new work — they help finish what is stuck. That single rule pulls the whole team toward finishing over starting, surfaces bottlenecks as visibly full columns, and replaces sprint commitment with a question asked per card: how long does an item take to cross the board? That measure, cycle time, is Kanban's velocity.

Kanban suits work that arrives continuously and unpredictably — support queues, operations, maintenance — where a two-week commitment would be fiction by Wednesday. Scrum suits product work that benefits from a steady cadence of planning and demonstration. A PHP product team commonly runs Scrum for feature work with a Kanban-style lane for urgent bugs, which is a deliberate blend rather than a failure to choose.

Done Criteria And Blocked Work

A board is only as honest as its definition of done. "Done" that means "code written" hides the risky remainder: review, tests, deploy, verification in production. Write the definition down — reviewed, merged, deployed, verified — and move cards only on evidence, such as the linked pull request merged and the release checked. A card moved to done before production verification is the board lying to the team.

Blocked work gets marked, dated, and named: what is it waiting on, and who owns unblocking it. A blocked card with no owner is where work goes to die quietly, and an aging report — cards untouched for a week — is the cheapest early-warning system a team can run.

Failure Modes

The universal failure is the board as decoration: updated before the meeting, ignored otherwise, while real coordination happens in chat. The fix is mechanical, not motivational — make the board the source of truth by linking cards to pull requests and deploys so most movement is automatic, and run standup from the board, walking columns right to left, instead of around the room. The second failure is unlimited work in progress: everything started, nothing finishing, and the fix is a WIP limit enforced even when it is inconvenient, because inconvenient is exactly when it is working.

What To Check

Before moving on, make sure you can:

• explain what a board makes visible and why chat cannot substitute for it
• describe Scrum's roles, ceremonies, and artifacts, and what a sprint commits to
• explain velocity and burndown, and why they are thermometers rather than targets
• describe Kanban's WIP limits, pull discipline, and cycle time
• choose between Scrum, Kanban, or a blend for a given kind of work
• write a definition of done that includes deployment and verification

What You Should Be Able To Do

After this lesson, you should be able to set up a board whose columns match your team's real workflow, run either sprints or WIP-limited flow over it deliberately, and spot the two classic failures — decorative boards and unlimited work in progress — early enough to fix them.