Boards

Kanban and Scrum boards for visualizing and managing work.

What Is a Board?

A board is a visual representation of work in progress. It displays tasks as cards arranged into columns, giving the team an at-a-glance view of what is being worked on, what is waiting, and what is done. Boards are the primary interface most team members use to interact with Work Ops day-to-day.

Rather than navigating lists and forms, team members drag cards between columns to update task statuses, scan the board to understand workload, and use filters to focus on what matters to them. Boards make the team's workflow tangible and visible.

Board Types

Work Ops supports two board types, each designed for a different way of working:

Kanban Boards

Kanban boards are built for continuous flow. There are no sprints or iterations — tasks move through columns from left to right as work progresses. New work enters from the left (typically a "To Do" or "Backlog" column) and exits on the right (a "Done" column).

Kanban is ideal for teams with a steady stream of incoming work, such as support teams, operations teams, or maintenance teams. The focus is on limiting work in progress, reducing cycle times, and maintaining a smooth, predictable flow of completed work.

Scrum Boards

Scrum boards are tied to sprints — time-boxed iterations of work. The board shows only the tasks committed to the current active sprint. When the sprint ends, the board resets for the next iteration.

Scrum boards are designed for teams that plan work in cycles, estimate effort, and track velocity over time. The sprint boundary creates a natural rhythm of planning, executing, reviewing, and retrospecting.

A project can have multiple boards. For example, a team might use a Scrum board for feature work and a separate Kanban board for production support — both showing tasks from the same project but filtered to different task types.

Columns

Columns are the vertical lanes that make up a board. Each column maps to one or more workflow statuses, creating the visual structure that represents the team's process.

For example, a simple development board might have these columns:

Column	Mapped Statuses	Purpose
To Do	Open, Reopened	Work that has not started yet
In Progress	In Development	Work actively being done
In Review	Code Review, QA	Work waiting for or undergoing review
Done	Closed, Resolved	Completed work

A single column can represent multiple statuses. In the example above, both "Code Review" and "QA" map to the "In Review" column. This keeps the board readable by consolidating related statuses into a single visual lane, even when the underlying workflow is more granular.

Conversely, each workflow status appears in exactly one column. This ensures every task has a clear, unambiguous position on the board.

WIP Limits

Work-in-progress (WIP) limits set a maximum number of tasks that should be in a column at any given time. WIP limits are a core Kanban practice that helps teams focus, reduces context switching, and surfaces bottlenecks.

When a column exceeds its WIP limit, the column header is visually highlighted as a warning. By default, WIP limits are soft — the system warns but does not prevent adding more tasks. This approach lets teams use WIP limits as guidelines while they develop the discipline to respect them, without blocking work in urgent situations.

Start with generous WIP limits and tighten them over time. A common starting point is to set each column's WIP limit to the number of team members who work in that stage, plus one. As the team improves flow, reduce the limits to expose bottlenecks.

Swimlanes

Swimlanes add horizontal rows to the board, grouping cards within each column by a shared attribute. They provide an additional dimension of organization beyond the column structure.

Boards support several swimlane options:

Assignee — Each team member gets their own row, making it easy to see who is working on what and whether anyone is overloaded.
Epic — Tasks are grouped by their parent epic, giving a view of progress across features or initiatives.
Priority — Critical and High tasks appear at the top, making urgent work immediately visible.
Project — On cross-project boards (at the program level), swimlanes can separate tasks by project while still showing them on a single board.
None — All cards appear in a single lane per column. This is the simplest view and works well for small teams.

Swimlanes can be collapsed individually, letting team members hide sections they are not focused on and expand only the lanes relevant to their current work.

Dragging Cards and Workflow Transitions

When a team member drags a card from one column to another, the system performs a workflow transition on the underlying task. This is a critical design principle: boards are a visual interface to the workflow, not a way to bypass it.

This means:

Transition rules apply. If the workflow requires conditions to be met (such as "assignee must be set") or validators to pass (such as "resolution is required"), the drag will prompt the user to satisfy those requirements.
Screens may appear. If the transition has an associated screen (such as a form asking for a resolution when closing a task), that screen is displayed before the transition completes.
Post-functions execute. Automated actions configured on the transition — like notifying watchers or updating related tasks — fire just as they would if the transition were triggered from a form.
Invalid moves are prevented. If the workflow does not allow a direct transition between the statuses represented by two columns, the card cannot be dragged between them.

This tight coupling between boards and workflows ensures that no matter how a task's status changes — through a board, a form, an API call, or an automation rule — the same rules and actions apply consistently.

Cross-Project Boards

At the program level, boards can span multiple projects. A cross-project board aggregates tasks from all projects within a program onto a single board, providing program managers and team leads with a unified view of work across teams.

Cross-project boards are especially valuable for:

Dependency tracking — Seeing work from multiple teams side-by-side reveals cross-team dependencies and blockers.
Standup meetings — A single board for the daily standup when multiple projects contribute to a shared goal.
Release coordination — Tracking which features from which projects are ready for an upcoming release.

Use project swimlanes on cross-project boards to maintain clarity about which team owns each card.

Filters

Filters control which tasks appear on a board. Every board has a base filter that determines its overall scope (such as "all tasks in this project" or "only bugs and stories"). Team members can apply additional quick filters to temporarily narrow what they see.

Common filter criteria include:

Task type — Show only bugs, or only stories and tasks
Assignee — Show only tasks assigned to a specific person, or only unassigned tasks
Priority — Focus on High and Critical items
Label — Filter by labels like "tech-debt" or "customer-reported"
Component — Show only tasks related to a specific part of the product
Epic — Focus on tasks belonging to a particular epic

Quick filters are temporary and personal — they affect only your view and reset when you leave the board. The base filter is configured by the board administrator and applies to everyone.

Use quick filters during standup meetings to focus on specific team members or priorities. After the meeting, clear the filters to return to the full board view.

Board Best Practices

Keep boards simple. Three to five columns is usually enough. Too many columns creates visual clutter and makes the board hard to scan at a glance.
Map columns to your real process. Columns should reflect the actual stages work goes through, not an idealized process no one follows.
Use WIP limits to find bottlenecks. If a column consistently hits its limit, that stage is a constraint. Investigate why and address the root cause rather than raising the limit.
Review the board regularly. Stale cards — tasks that have not moved in days — indicate blocked work or forgotten tasks. Address them in standups.
Choose the right swimlane for your context. Assignee swimlanes work well for daily standups. Epic swimlanes work well for planning and progress tracking. Switch between them as needed.