An Editorial Calendar Is a Capacity System, Not a Wish List

The calendar should govern entry, not display ambition

An editorial calendar is useful when it controls which work enters production and why. A page filled with future titles may communicate intent, but it says nothing about whether research, drafting, review, publishing, and maintenance can all finish. Treat the calendar as the visible edge of a workflow. Every commitment should consume known capacity in a defined stage, and every stage should have an owner, an exit condition, and a limit on unfinished work.

This changes the planning question from “How many ideas can we schedule?” to “How many items can the whole system complete without starving review or refresh work?” The Kanban Guide defines work in progress and flow measures such as throughput, work-item age, and cycle time. Those concepts do not prescribe an editorial method, but they provide a disciplined language for seeing congestion that a date-only calendar conceals.

Evidence: Kanban Guides

Work-in-progress limits reveal the actual constraint

When too many articles start at once, each waits longer for scarce attention. A writer may appear busy while drafts age in review, evidence checks accumulate, and published pages miss scheduled updates. A work-in-progress limit caps the number of items allowed in a stage or across the system. Once the cap is reached, the next action is to help finish, unblock, narrow, or cancel existing work—not open another draft.

Limits should be based on observed capacity and risk rather than copied from another team. A solo publisher might allow one research item, two drafts, and one review. A team with specialist reviewers may use different numbers. The limit is a trigger for conversation, not a productivity target. If an urgent correction enters, explicitly displace or pause something else so the emergency does not silently expand total load.

• Count items that have started but are not truly done.
• Make blocked and aging work visible beside active work.
• Require an explicit trade when urgent work crosses a limit.

Evidence: Kanban Guides; Scrum Guides

Estimate capacity from completions and service demand

Begin with several weeks of completed work, not an aspirational output quota. Separate new articles, substantial refreshes, minor corrections, and unplanned support because they consume different mixes of effort. Record the full elapsed time as well as touch time when possible. A stable median can be a planning reference, but preserve the spread and the oldest items; averages alone can hide a review queue that occasionally stalls for weeks.

DORA discusses balanced delivery measures and warns against turning metrics into cross-context targets. Editorial work is not software delivery, so the metric names should not be imported as causal proof. The transferable lesson is to examine speed together with stability and outcome. For a publisher, that may mean completions, age, correction volume, source-review quality, and reader usefulness rather than celebrating raw publishing frequency.

Evidence: Kanban Guides; DORA / Google Cloud

Reserve lanes for research, release, and renewal

A sustainable mix protects work that produces no new URL. Research develops future evidence; review reduces unsupported claims; accessibility and technical checks protect the reading path; refresh work keeps older pages trustworthy. If every available slot is assigned to a new draft, these responsibilities become invisible debt. Establish capacity shares or protected lanes, then revisit them when the age or risk profile of the library changes.

The Scrum Guide offers a contrasting fixed-cadence model in which a goal focuses a short period and review creates an opportunity to adapt. An editorial team can use a cadence without pretending every article is equal-sized. The important boundary is that replenishment happens at a known decision point and the team does not continuously add commitments between reviews. A calendar may combine a pull board with a weekly or fortnightly planning rhythm.

Evidence: Scrum Guides; UK Government Digital Service

Artifact: the capacity-based editorial board

Build columns for Ready, Research, Draft, Evidence Review, Production Check, Scheduled, and Published or Refreshed. Put an explicit definition at the top of each column. Add WIP limits only to active stages, show the start date on every card, and distinguish content type with a small marker. A blocked card remains inside its limit because the capacity is still occupied. Add a separate expedite policy rather than a permanent “urgent” lane.

Below the board, display four dated observations: completions by type, median and oldest item age, number returned from review, and refresh obligations due next. Use them during replenishment to decide what the system can safely accept. The board is an operating artifact, not evidence that a particular limit is optimal. Change one policy at a time and record why, otherwise a later improvement or decline cannot be interpreted.

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

Where the model stops being reliable

Editorial items vary in uncertainty, legal sensitivity, source availability, and revision depth. A simple card count can mislead when one investigation equals ten lightweight updates. Class-of-service markers or rough size bands can help, but excessive estimation creates its own burden. Seasonal campaigns may also justify temporary capacity changes. Document the exception, its end date, and what routine work is displaced rather than treating the peak as normal capacity.

Start by reconstructing the last four weeks on a board and marking where each completed or unfinished item waited longest. Set only one tentative WIP limit at the clearest bottleneck, then observe age and completion for two replenishment cycles. This is an illustrative operating method, not a TenMultigure performance claim. The cited guides explain flow and iterative learning; they do not guarantee that a specific board design will improve quality or revenue.

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