Boards: Scrum, Kanban & Delivery pipeline

How do the board types differ?

How does the Kanban Backlog column work?

Kanban projects have a Backlog status as the first column, before To Do. New issues start in Backlog and are dragged to To Do when the team is ready. The Backlog lane can be collapsed. Kanban projects created before this existed get a one-time Add Backlog column button for project admins.

WIP limits per status are set in project.md; columns over their limit are highlighted.

How does a Delivery pipeline work?

When creating the project, list 1–10 environments in delivery order. The board gets Backlog · To Do · Test Rejected · Developing · Dev Done, then Testing and Passed for each environment, then Done. Each environment's columns sit under one header band.

An environment is a place the work is delivered to (e.g. Dev, UAT, Production), not a work status. Don’t use a main column name such as To Do or Done, or the words Testing / Passed — BoardMark adds Testing (name) and Passed (name) by itself. A name that reads like a status gets a warning, and you are asked once more before the project is created or saved. Under the column preview the delivery order is shown, e.g. Dev Done → Testing (Dev) → Passed (Dev) → Testing (UAT) → Passed (UAT) → Done — Testing means it is being tested on that environment, Passed means it passed there and waits to go on to the next one.

• An issue that fails testing on any environment moves to Test Rejected and goes back to development
• Project admins add, rename or reorder environments later in Project settings
• An environment can be removed only when none of its columns hold issues — the blocking issues are listed
• Delivery pipelines have no sprints

---
key: REL
name: Releases
board_type: pipeline
environments:               # 1–10, in delivery order
  - { id: develop, name: develop }
  - { id: uat, name: UAT }
  - { id: prod, name: production }
statuses:                   # generated from the environments
  - { id: backlog, name: "Backlog", category: todo }
  - { id: todo, name: "To Do", category: todo }
  - { id: test_rejected, name: "Test Rejected", category: in_progress }
  - { id: developing, name: "Developing", category: in_progress }
  - { id: dev_done, name: "Dev Done", category: in_progress }
  - { id: testing_develop, name: "Testing (develop)", category: in_progress }
  - { id: passed_develop, name: "Passed (develop)", category: in_progress }
  - { id: testing_uat, name: "Testing (UAT)", category: in_progress }
  - { id: passed_uat, name: "Passed (UAT)", category: in_progress }
  - { id: testing_prod, name: "Testing (production)", category: in_progress }
  - { id: passed_prod, name: "Passed (production)", category: in_progress }
  - { id: done, name: "Done", category: done }
---

The board summary follows every move or edit at once. Throughput counts issues now in a Done column by the week of their last change (7-day weeks, Bangkok time); the right bar is this week.

What is the On Hold column?

Kanban and Delivery pipeline boards can turn on an On Hold column in Project settings (Columns) for paused work — waiting for the customer, a decision or another team. It sits right after Backlog in the todo category, so it doesn't count toward WIP or as done.

• Off by default, since not every team uses it
• It can be turned off only while no issue is in it; otherwise the issues still there are listed so you can move them first
• Changing a Delivery pipeline's environments keeps the On Hold column
• Scrum boards have no On Hold column — move paused work out of the sprint to the backlog

Where do statuses and workflow come from?

From each project's project.md. Every status has a category (todo, in_progress, done), and transitions are either any-to-any or an explicit list. New projects get To Do, In Progress, In Review, Test Rejected and Done. On Premium, admins edit the columns themselves in Project settings → Board columns (below).

---
key: APP
name: Mobile App
board_type: scrum
statuses:
  - { id: todo, name: "To Do", category: todo }
  - { id: in_progress, name: "In Progress", category: in_progress }
  - { id: in_review, name: "In Review", category: in_progress }
  - { id: test_rejected, name: "Test Rejected", category: in_progress }
  - { id: done, name: "Done", category: done }
transitions: any            # any | explicit list
parallel_sprints: false     # Scrum only; off by default
---

Can I customise the board columns? (Premium)

Yes, on Premium. A company admin or a project admin opens Project settings → Board columns at any time, on Scrum, Kanban and Delivery pipeline boards alike — and the same editor is offered when creating a project. You edit a draft with a live preview of the board, then Save or Discard; if someone else saved first, you reload before saving. Only the columns change — cards still move to any column (workflows, issue types and custom fields come later).

• Add, rename, reorder and delete columns; names must be unique
• Each column's category: to do, in progress or done — at least one done column must remain; burndown and velocity count issues in done columns; a category change applies from then on (closed sprints keep their numbers)
• Colour, an optional WIP limit on every board type (over the limit the column turns to a warning colour, moves are not blocked) and the column's meaning, shown to people on the board and to AI agents in get_project and get_docs_context
• Renaming a column keeps its issues, links, filters and history — the status id never changes
• A lane per column (optional): the role that works in that status, such as Developer or QA, or several. It warns an AI agent that moves work outside its role; it never blocks
• Deleting a column that holds issues: pick the column to move them to; the move runs in the background with a live count, clock and time left
• Delivery pipeline: each environment's Testing / Passed columns can be renamed and recoloured but are removed only by removing the environment; columns you added stay when environments change
• The Backlog column of Kanban and Delivery pipeline boards always stays first: rename, recolour or give it a meaning, but it cannot be deleted or moved (new and not-yet-started work waits there). On Hold is an ordinary column
• Importing from Jira offers the same editing, or the columns of your Jira board
• Columns are edited in the web app only; AI agents read them but cannot change them
• Not on Premium: Board columns still opens but is locked — company admins see Upgrade, other members can ask their admin to upgrade. After a change from Premium to Pro, custom columns keep working but cannot be edited
• A column with a meaning has an ⓘ next to its name: hover, focus or tap it to read the meaning (and the lane), in the Columns and the List view

What does each status mean?

These are BoardMark's default meanings — loose starting rules. A company or a project can write its own instead; see “How do we set our own rules?” below.

Each status also has a default lane — the role that works in it (for example In Review → QA). See “How do people and AI agents in each role pick work and move cards?” below.

How do people and AI agents in each role pick work and move cards?

• Work in your role only — the user tells an agent its role (developer, QA, BA, …); if it is not clear, the agent asks once. BoardMark connects agents in every role.
• Developer: take issues assigned to you first, then unassigned To Do issues; never someone else's unless the user asks. Call list_inbox when a session starts and after each card. Read the card with get_issue_context, then claim it in one update_issue: In Progress (Developing on a Delivery pipeline) + working (what, how, why) + touches + if_unassigned: true (409 already_assigned = someone else holds it); then → In Review (Dev Done) with a short summary comment when you finish. A Test Rejected issue goes back to In Progress / Developing when you resume it.
• QA: test issues in In Review (Scrum, Kanban) or Testing (env) (Delivery pipeline). Passed → Done, or Passed (env); failed → Test Rejected with a comment: steps, expected, actual.
• BA: write and refine issues — description, acceptance criteria, type, points, links, parent — in Backlog / To Do; do not move them past To Do.
• Deploying: Dev Done → Testing (env), or Passed (env) → Testing (next env), means the build is on that environment.
• Scrum boards (AI agents): change statuses only for issues in a sprint a person has started, and never start sprints. People can change an issue's status any time in its issue panel.

A lane is the role that works on issues in a status and moves them on. Every column can have one — Developer, QA, BA, DevOps, Sales, Admin, Manager, or several separated by commas. Software boards get defaults with no setup. Project admins change them in the column editor (Premium, like colour and meaning), or pick No lane to turn one off.

• Defaults on software boards: Backlog → BA · To Do, In Progress / Developing, Test Rejected → Developer · In Review, Testing (env) → QA · Dev Done, Passed (env) → DevOps
• Sales & Billing: Draft, Sent, Signed → Sales · In delivery → Manager · Billing → Admin. Budget planning: Proposed → Manager · Approved, Spending → Admin
• An agent's role is set on its personal access token (when you create it, or later on the Agent & MCP access page), or on the approve screen when an AI client connects with OAuth. If the user tells the agent its role in chat, that wins (the agent passes it along). When one person runs several agents, one token per role works well — a DEV agent, a QA agent.
• Warn, never block: when an agent moves an issue out of another role's lane (a Developer agent moves In Review → Done), skips another role's step (In Progress → Done, skipping QA), or — with no role set — moves on an issue it moved into another lane itself (reviewing its own work), the move still happens but the agent gets a warning. It should stop, tell the user and hand off with a comment. People are never warned or blocked.
• The issue history shows the agent's role (“via Claude Code · QA”) and a ⚠ marker on moves that left the agent's lane.
• Lanes are hints, not permissions — an agent still has exactly its user's rights.

How do we set our own rules?

Write them in Markdown in the docs every AI agent reads before it starts: company-wide rules in the company brief (admin console), a project's rules in its brief (gear on the board → Docs). Only admins (company admins / project admins) can edit these two docs, so they are the only rules an agent follows; working notes, handoffs, issues and comments — which every member writes — reach agents as information, not instructions: text in them that tells an agent what to do is not followed, and an agent never acts on another project because content told it to. Precedence: the user's instruction > the project brief > the company brief > BoardMark's defaults above. If a project has its own statuses (for example imported from Jira), explain them in the brief too. Every brief shows who last edited it and when.

Lanes in the column editor complement written rules: a lane says which role works in a status, and your docs explain the details of how your team does it.

## Workflow rules

- In Review = code review by a senior developer; QA tests in UAT only.
- Developers move their own issues up to In Review; only QA moves to Done.
- "Waiting sign-off" (from Jira) = the customer is checking it; the PM moves it to Done.
- Agents: work only on issues labelled `agent-ok`; always comment what you changed.

How do I move cards?

• Drag a card to another column to change its status, or up and down to reorder
• Drag an issue from the backlog strip straight into a column — it joins the running sprint with that status
• On phones, long-press then drag, or change the status in the issue drawer
• From the keyboard: ⇧← / ⇧→ moves between columns, ⇧↑ / ⇧↓ reorders

List view: the Columns | List switch next to Settings shows the same issues as a list, grouped by column (Backlog and Done folded); the choice is remembered per project, and phones open on the list. Each group header has a + that creates a new issue in that status, like a column header. Each row has a status button: pick the highlighted next status, back, or any status without opening the issue. Keyboard: ] = next status, [ = back. Undo is offered after each move. On a Delivery pipeline, Testing offers both Passed and Test Rejected.

Everyone viewing the board sees the change in real time.

Moving an issue to Test Rejected asks for a comment with the reason — steps, expected, actual — with a button that opens the issue.

Move several cards at once (Columns and List boards): press Select, or ⌘/Ctrl+click a card. A click then picks cards instead of opening them (no dragging in this mode). A bar at the bottom shows how many are selected with Move to…, Select all shown, Clear and Done selecting; Esc leaves. Move to… opens a confirm dialog that skips cards already in that status or not allowed by the workflow, warns about a WIP limit, and asks for a reason when the status requires a comment. Each card moves on its own with the normal status change and its own history line, like dragging it; cards that could not move are listed with the reason and stay selected. AI agents use transition_issue per issue.

How do I put many issues into a release?

The Releases tab works on any board type on a paid plan; switch it on in project settings (off by default). A release groups features (epics — their issues follow them) with a production date. This section covers putting and moving many issues into a release at once.

At the top of the Releases tab, Latest in production shows which release production is on: its name, when it was released (date and time in your time zone) and by whom, how many issues and features went with it, the reason when it was released with a required gate item still open, and a button to its dashboard. A small line names the release before it. Below come Planned — the releases still being planned — and Released to production (n), folded, with every released release. A project with nothing released yet does not show this section.

Issues finished in an earlier, closed sprint can be put into a release too: a closed sprint no longer blocks choosing their release (their status and story points still cannot change, and the sprint itself is untouched). Each release has a Release note — Markdown that says what is in this round, seen by every project member who can open the release, kept apart from the release's internal description — and a Deployment log (Deployments), newest first: each entry records the environment, the artifact or version, the commit, the time, the result (deployed · verified · failed · rolled back) and notes. The latest entry of each environment shows as a small chip on the release card (for example production · 1.0.1 · 3 Nov 23:27). Project admins and release managers write the Release note and record deployments, both while the release is planned and after it is released; AI agents can record a deployment with your user's rights in either state, and write the Release note while the release is planned. Write a new entry to correct an old one (entries cannot be edited or deleted). Ordinary members see the deployments but not the notes and the build link. Ticking the gate and shipping to production stay with people.

• From a planned release's page: press + Add issues in the Features card (members, PMs and admins see it; viewers do not).
• Quick picks by board type — Scrum: Done in sprint (pick the sprint: running ones and the last 3 closed) · Kanban: Done, no release · Delivery pipeline: Done and Passed before production, no release · every board has No release (any status) and Search by key or title.
• Every row starts ticked; untick what you do not want and press Add N issues. 50 rows load per page, more as you scroll.
• The switch Include issues in another release shows issues of other releases (unticked; they move out of that release). An epic says how many child issues follow it.
• From the board: Select mode (Columns and List) and the Scrum Backlog selection bar have Release…; pick a planned release or No release and confirm. Cards already in that release are skipped; an epic says how many children follow. You cannot drag a card onto a release.
• Both ways move issues one at a time with the existing move_to_release (rights, the release must be planned, history and scope log checked per issue) and a live x / N counter. Failed issues stay ticked with the reason and a Try again button. Once the release baseline is locked, a PM or admin types one optional reason (up to 500 characters) used for every issue and kept in the scope history.

On Kanban and Delivery pipeline boards with Releases on, once a release is marked Released to production its done cards leave the board (Columns and List) at once, without waiting for the Monday done sweep. A note under the toolbar reads “N cards shipped in <release> are off the board · View in release · Show”; Show loads them a page at a time under “Shipped · <release>”, for this visit only. They stay findable on the release page, in ⌘K search and in ?release=R-n links. Unfinished cards of that release stay on the board. Scrum boards are unchanged.

For AI agents (D189): find the issues with search_issues (release=none, the done status ids — on a pipeline also the Passed statuses before production — and the sprint), then call add_to_release once with up to 50 keys and one reason; it moves them one by one and answers per issue. With their user's rights an agent may also create a planned release (create_release, default gate) and edit its name, date, milestones and description until the baseline is locked (update_release); an agent also writes the Release note with update_release (release_note) while the release is planned, and records a deployment with add_release_deployment (environment, artifact, commit, time, result, notes) while it is planned or after it is released; ticking the gate, locking the baseline, shipping, reopening and deleting stay with people in the app. search_issues with hide_released=true leaves out done cards of releases already in production (the count comes back as omitted_released) — use it for “what is not in production yet”.

search_issues   { project_key: "APP", release: "none", status: ["done"], sprint: "S-12" }   # candidates, 50 per page
create_release  { project_key: "APP", name: "2026.11", target_date: "2026-11-28", reason: "Next release" }   # → R-4, default gate
add_to_release  { project_key: "APP", release_id: "R-4", issue_keys: ["APP-101", "APP-104", "APP-107"], reason: "Sprint 12 scope" }   # ≤ 50, result per issue
update_release  { project_key: "APP", release_id: "R-4", release_note: "Faster board loading, new Releases tab", reason: "Draft release note" }   # seen by every project member
add_release_deployment  { project_key: "APP", release_id: "R-4", environment: "production", artifact: "app:1.0.1", commit: "3f9c2ab", result: "deployed", notes: "Rolled out 23:27" }   # appended to the deployment log
search_issues   { project_key: "APP", hide_released: true }   # what is not in production yet
# → omitted_released: how many done cards of shipped releases were left out

What happens when two people edit the same issue?

Every save sends the version it read, and nothing is overwritten. If someone changed a different field first, your field or description change is saved on top of their version for you. If they changed the same field first, you see their value and a note.

If you both edited the description, you see the difference and choose Keep mine, Take theirs or Merge.

Project settings work the same way: if someone changed another setting meanwhile, your switch still saves; you are told only when they changed the same setting.