A fast board and real sprints, without the scrum tax

A scrum board is a simple thing wearing a heavy process. At its core it is a two-dimensional view of a single sprint's work: columns for status (usually To Do, In Progress, Done), cards for the issues moving across them, so at a glance the whole team can see what is queued, what is in flight, and what shipped this cycle. That is the board. Everything else that gets attached to it, the estimation rituals, the velocity charts, the ceremonies with names, is the scrum framework, not the board itself.

This post is about keeping the useful part and dropping the tax. You can have a fast board and real, time-boxed sprints without adopting the whole scrum apparatus, and for most software teams that is exactly the right amount.

#What a scrum board actually is

Strip scrum down to what shows up on the wall (or the screen) and a scrum board has three parts:

• Columns for workflow state. The minimal set is To Do, In Progress, Done. Some teams add In Review or Blocked. The columns represent where a piece of work is, not what it is.
• Cards for the work. Each card is one issue: a title, an owner, a priority, an estimate if you use them. You move the card rightward as the work progresses.
• A sprint boundary. The board shows this sprint's work, not the entire backlog. That time-box is what makes a scrum board a scrum board rather than a generic kanban board. It is scoped to a cycle with a start and an end.

That is the whole primitive. A team that has those three things, columns, cards, and a bounded sprint, is running a scrum board, whether or not they hold a single ceremony.

#Scrum board vs kanban board

This is the most common question about scrum boards, so it is worth answering directly. Both are column-and-card boards. The difference is the time-box.

A kanban board is continuous. Work flows in and out as capacity allows; there is no reset. The board is the ongoing state of everything, often with a limit on how many cards can sit in a column at once (work-in-progress limits).

A scrum board is scoped to a sprint. At the start of the cycle you pull a bounded set of work onto the board; at the end you close the cycle, ship what shipped, and roll the rest into the next one. The board resets. That reset is the entire distinction. Scrum boards are also where teams that care about it hang metrics like sprint burndown, though those charts are a scrum practice, not a requirement of having a board.

Practically: if your team plans in two-week batches, you want a scrum board (a board bound to a cycle). If your team pulls work continuously with no fixed cadence, you want a plain kanban board. Some tools give you both layouts over the same issues, which is the sane default.

#The scrum tax, and how to skip it

Here is where scrum boards earn their bad reputation. The board is fine. The framework that accretes around it is the problem: the story-point poker, the three standing ceremonies a week, the retro on the retro, the velocity dashboard that turns an estimate into a performance metric. None of that is required to move a card from To Do to Done. It is optional process that a tool made easy to turn on, and once on, it becomes a tax on every issue forever.

The lean version keeps the two things that actually earn their keep, the board and the sprint boundary, and treats the rest as opt-in. You get the visual state and the time-box. You skip the ceremony unless your team genuinely wants it.

This is the honest place to say what Radial does and does not ship, because "without the scrum tax" has to mean something concrete. Radial gives you board and list layouts over your issues, Cycles (time-boxed sprints with a start and end), estimates, a triage step for unsorted work, and priorities. That is a real scrum board and a real sprint. Radial does not ship burndown charts, velocity graphs, scrum dashboards, or ceremony tooling, and that is deliberate, not a missing feature we are rushing to add. If a burndown chart reporting up to leadership is load-bearing for you, Radial is honestly the wrong tool, and Jira exists for exactly that. If what you want is the fast board and the bounded sprint minus the reporting apparatus, that is the whole design.

#Run the board from the terminal

The other thing a scrum board should be, and rarely is, is scriptable. When the board lives behind a web app you can only click, keeping it current is manual work: someone drags a card, someone updates a status in a meeting. When the tracker has a real CLI, the board updates itself as a byproduct of the work.

Every Radial command takes --json, and issues carry a --cycle, so you can file work straight onto the current sprint's board and read the board back as data:

# File an issue onto sprint 12's board, high priority, with an estimate
radial create "Fix the flaky checkout test" -t ENG -p high --cycle 12 --estimate 2 --json

# Read that sprint's board back as data you can pipe into anything
radial list --cycle 12 --status "in progress" --json

Because --json is on everything and the cycle is just a flag (referenced by its number), the board stops being a place you visit and becomes something you script into your workflow. A CI job can file a failing-build issue directly onto the sprint. A pre-commit hook can check what is on your plate this cycle. And your coding agent can do the same operations over MCP, filing and moving cards onto the sprint board using the identical API a human uses. Every credential is a client of the API, not a billed seat, so your agents ride free. There is no per-agent charge for letting Claude Code or Codex keep the board current.

#The bill should be boring too

A note on pricing, because it is part of the "without the tax" promise. Most scrum tools are per seat per month, and most now meter AI work on top of that, a credit allowance per seat, a separate charge per agent that touches the board. The number you sign up for is not the number you pay.

Radial is one number: $50 per user, per year, flat, billed annually, locked at the rate you join. No per-agent seats, no AI credits, no usage meter, because there is no AI in the product to meter. That is backed by the Plain Software Pledge, written down: the day Radial ships a copilot, meters your usage, or charges you for AI you did not ask for, your subscription is free. This is not anti-AI. Your agent doing real work on the board is exactly the point. The intelligence just lives in your agent, not billed inside the tracker.

#FAQ

#What is a scrum board?

A scrum board is a visual board that shows one sprint's work as cards moving across status columns (typically To Do, In Progress, Done). Its defining feature is the sprint boundary: unlike a continuous kanban board, a scrum board is scoped to a time-boxed cycle that starts, ends, and resets. It gives a team an at-a-glance view of what is queued, in progress, and done for the current sprint.

#What is the difference between a scrum board and a kanban board?

Both are column-and-card boards; the difference is the time-box. A kanban board is continuous, work flows in and out with no reset and often a work-in-progress limit per column. A scrum board is bound to a sprint: you pull a fixed set of work onto it at the start of the cycle and reset at the end. Scrum boards are also where teams hang sprint metrics like burndown, though those charts are a scrum practice, not a requirement of the board. Many trackers, Radial included, let you view the same issues as either a board or a list.

#What does scrum stand for?

Scrum is not an acronym. The name comes from rugby, where the team packs together in a "scrum" to move the ball forward as a unit. The framework borrowed the word to describe a small, cross-functional team working in tight, iterative cycles. So "scrum board" just means the board a scrum team uses to track a sprint, there is no hidden expansion.

#What are the common pitfalls of a scrum board?

The usual ones: overcrowding the board with more work than a sprint can hold, letting cards go stale because updating the board is a separate chore, inconsistent use across the team, and unclear columns or labels. Most of these come from friction, if keeping the board current is slow, people route around it. The fix is a fast board that updates as a byproduct of the work (ideally scriptable from the CLI or driven by your agent), and resisting the temptation to bolt on ceremony the team will not actually maintain.

#Do you need the whole scrum framework to use a scrum board?

No. The board and the sprint boundary are the load-bearing parts. The estimation rituals, the standing ceremonies, and the velocity dashboards are optional scrum practices you can adopt or skip. Plenty of teams run a time-boxed board, ship every cycle, and never hold a formal ceremony. Keep the board and the sprint; treat the rest as opt-in.

#The short version

A scrum board is columns, cards, and a sprint boundary. That is the useful part. The ceremony and the dashboards are the tax, and they are optional. Radial ships the board, the list, real Cycles, and estimates, scriptable from the terminal and drivable by your agents, at one flat locked $50 per user per year with no AI meter. It does not ship burndown charts or velocity graphs, on purpose.

See the one number on pricing, or read how the same CLI turns the tracker into something you script in engineering project management without the overhead.