Prepare evidence before the planning session

Gather the previous four to eight weeks of work and classify each item as new publication, major refresh, minor correction, research, or operational support. Record when it entered active work, when it finished, and where it waited if that is recoverable. Do not discard abandoned or blocked items; they reveal capacity consumption that a list of published URLs misses. Bring the next month of fixed obligations, including promised updates and dated campaigns, but leave speculative ideas in a separate pool.

The purpose is not to calculate a perfect forecast. It is to establish a credible starting range and identify the stage most likely to constrain flow. Use median completions by class, the age of the oldest unfinished item, and reviewer availability. The Kanban Guide supplies definitions for throughput, work-item age, and cycle time, while its generality means you must define what an editorial work item and completion actually mean.

Evidence: Kanban Guides

Draw the workflow and write exit rules

Create columns that follow the real path rather than an idealized process. A practical sequence may be Selected, Researching, Drafting, Editorial Review, Production Check, Scheduled, and Done. Under each heading, write the evidence required to move right. “Draft complete” might require a direct answer, traceable sources, labeled uncertainty, and a proposed title; “production checked” might require links, metadata, mobile reading, disclosure, and accessibility review.

Include rework. If a review sends an article back, the card returns to the stage where the missing condition can be repaired and continues to occupy capacity. Define Done for both publication and refresh, including any post-release verification. The Scrum Guide’s emphasis on a shared Definition of Done is useful here, even though an editorial board need not use Scrum roles or events.

Name every active state a card can genuinely occupy.

Write observable exit evidence below each state.

Show review returns instead of hiding them in comments.

Define completion for new pages and updates separately.

Evidence: Kanban Guides; Scrum Guides

Set provisional limits from the constraint outward

Find the stage with the least reliable capacity—often evidence review or production—and start there. If one reviewer can responsibly finish three items in a typical week, allowing twelve drafts to queue is unlikely to improve output. Set a small combined limit for work approaching that stage, then place limits upstream so drafting cannot flood it. Leave headroom for corrections; a board filled to theoretical maximum has no way to absorb urgent quality work.

Use whole numbers and make the policy visible. A limit of two means a third card cannot enter until one leaves or an explicit exception is approved. Do not assign each person a private quota because that discourages collaboration at the bottleneck. The team should swarm to finish or remove an item. The first limits are hypotheses and should be revised from observed age, quality, and completion—not discomfort with seeing an empty column.

Evidence: Kanban Guides; DORA / Google Cloud

Protect maintenance and discovery capacity

Divide replenishment capacity before selecting titles. One simple starting policy might reserve half for new evergreen work, one quarter for scheduled refreshes and corrections, and one quarter for research or experiments. Those shares are illustrative, not universal. A young library may need more new work; an older or high-risk library may need more maintenance. What matters is making displacement explicit whenever a campaign demands a temporary shift.

GOV.UK’s alpha guidance supports spending early effort on risky questions instead of prematurely completing an entire service. Translate that idea into an editorial discovery lane with a strict exit: the work must either produce an article brief, identify missing evidence, or close. Research without a decision can become another hidden queue, so give discovery items owners, expiry dates, and their own small limit.

Evidence: DORA / Google Cloud; UK Government Digital Service

Run replenishment as a weekly decision

At the weekly meeting, review the oldest active card first, then blocked items, due maintenance, and remaining capacity. Pull new work only when a downstream slot exists. Select by evidence need, reader value, timeliness, and strategic fit rather than whichever title is most exciting. Assign an owner for the next state, not every future step. End by noting one risk that could invalidate the plan before the next meeting.

Use a compact record: date, completed items by type, items older than the expected range, exceptions granted, cards pulled, and policy changes. This creates an audit trail without turning the board into bureaucracy. If no card completes for a week, do not automatically increase limits; inspect the constraint, review definition, or item size first. More starts usually lengthen the queue.

  • Review age before adding work.
  • Pull only into available downstream capacity.
  • Record every exception and what it displaced.
  • Close with one named risk and owner.

Evidence: Kanban Guides; Scrum Guides; DORA / Google Cloud

Evaluate the first two cycles without gaming them

After two replenishment cycles, compare completion mix, oldest item age, return-from-review count, and unplanned work. Ask whether maintenance remained protected and whether reviewers experienced batching or interruption. Do not rank individuals or declare causality from such a short period. A change in campaign mix, absence, or unusually difficult research can explain movement. Keep the old policy visible and change one rule at a time.

A useful next action is to schedule a ninety-minute setup session, reconstruct recent work, and leave with column definitions plus one downstream limit. Delay filling future dates until the board exposes genuine capacity. This guide offers a worked procedure, not evidence that ninety minutes or any sample limit fits every publisher. Revisit source guidance and local observations by 2027-02-10 or sooner if team structure or publishing risk changes.

Evidence: Kanban Guides; DORA / Google Cloud; UK Government Digital Service

Sources and further reading

These references informed this article. A source supports a claim; it does not imply endorsement of TenMultigure or any future product reference.

  1. The Kanban GuideKanban Guides · Accessed August 10, 2026

    Used as the procedural basis for mapping actual workflow, defining work items, and setting visible work-in-progress policies from recent flow observations instead of ambition.

  2. The Scrum GuideScrum Guides · Accessed August 10, 2026

    Supports writing a shared completion definition and using a recurring review cadence; the method borrows those controls without claiming that an editorial team has adopted Scrum.

  3. DORA’s software delivery performance metricsDORA / Google Cloud · Accessed August 10, 2026

    Informs the balanced evaluation step and the warning against optimizing a single speed measure or comparing individual contributors through system-level delivery metrics.

  4. How the alpha phase worksUK Government Digital Service · Accessed August 10, 2026

    Supports a tightly bounded discovery lane that tests uncertain questions before full production, preventing research from becoming an unlimited holding area.

Reviewed for clarity and evidence

Reviewed by TenMultigure Editorial Team. See an error or a source that has changed? Tell the editorial team.

Review method: AI-assisted desk research with editorial checks. Reviewed ; next scheduled review . Converted TM-207 into a sequential setup workshop using recent completion evidence, explicit exit rules, constraint-led WIP limits, protected maintenance capacity, and a weekly pull ritual.