Why We Ditched Our Separate Kanban Board and Synced GitHub Instead

For a long time, the team in this example ran a beautiful Kanban board in a standalone tool—and a parallel reality on GitHub that never quite matched it. This is the story of why they ditched the separate board and adopted a github kanban board instead: one where columns are GitHub labels that sync both ways, so the board and the repository can’t disagree.

Two boards, one source of confusion

The standalone Kanban tool was genuinely nice to look at. The problem was that it had no idea what was happening in the code.

Every card was a manual echo of GitHub:

• A PR merged, but the card still sat in “In Review” until someone dragged it.
• A label changed on GitHub, but the board column didn’t move—because the board didn’t know GitHub existed.
• A reviewer left a comment on the PR, but the Kanban card’s discussion thread stayed empty, splitting the conversation across two places.

The team had built a careful, color-coded board that was, on any given afternoon, subtly wrong. Standups turned into reconciliation meetings. The delivery lead called it “maintaining a diorama of our work instead of doing the work.”

The realization: the board should be a view of GitHub, not a copy of it

The breakthrough was a reframing. They didn’t need a board that represented GitHub. They needed a board that was GitHub, rendered as columns.

That’s what a github kanban board with two-way label sync gives you. Instead of cards as separate objects you keep in sync by hand, each column corresponds to a GitHub label:

Ready for Testing   ←→  label: ready-for-testing
In Progress         ←→  label: qa-in-progress
Passed              ←→  label: qa-passed
Failed              ←→  label: qa-failed

Move a card to “Passed” and the qa-passed label appears on the real PR. Someone changes that label directly on GitHub, and the card moves on the board. There’s no copy to drift, because there’s no copy at all—just two views of the same labels.

What changed when GitHub became the board

The team migrated their workflow into a workspace where pull requests, issues, sprints, and milestones are scoped per project and read live from GitHub. The standalone tool got archived within two weeks.

The day-to-day differences were immediate:

• Columns were always accurate. Because state lives in GitHub labels and syncs both directions, the board reflected reality without anyone dragging cards to “fix” it.
• Comments stopped fragmenting. Feedback posted to the real GitHub PR, so the conversation lived in one place—next to the diff—instead of split between a card and the repo.
• Engineers never left GitHub. They saw QA’s workflow state as labels on their PRs. Testers saw the queue as columns. Same data, two comfortable surfaces.

The two-way part is the whole point

Plenty of tools can read GitHub. The team’s old setup could even import PR links. What it couldn’t do was write back—so the moment a human did anything on GitHub directly, the board lied.

Two-way sync closed that gap. Whether a state changed from the board or from GitHub, both surfaces agreed within moments. That single property eliminated the reconciliation ritual that had defined their standups.

Beyond the board: what they gained by consolidating

Killing the separate tool did more than fix the columns.

Workflow labels became a shared language. Defining the columns meant defining the labels, and defining the labels meant the whole team—engineering and QA—used the same four words for the same four states. No more “done” meaning three different things.

Sprints and milestones lived with the work. Planning artifacts weren’t in a third tool; they sat in the same project as the repositories and PRs, scoped per project.

Roles replaced free-for-all editing. The standalone board let anyone move anything. With granular roles—owner, manager, tester, viewer, and custom roles—the team could give stakeholders a read-only view of the board without risking stray edits.

How to make the switch cleanly

If you’re staring at a standalone Kanban board that never matches GitHub, here’s the path the example team took:

1. Agree on your columns as labels. Pick a small set of workflow states and the exact GitHub label names. Few and unambiguous beats clever.
2. Wire two-way sync. Confirm that moving a card writes the label to GitHub and a label change on GitHub moves the card. One direction isn’t enough.
3. Move comments to the PR. Route QA and review feedback to the real pull request so the conversation stops splitting.
4. Run parallel for a week. Keep the old board read-only as a confidence check, then archive it on a fixed date.
5. Set roles before sharing. Decide who edits the board and who only watches it.

Key takeaways

• A standalone Kanban board fails because it’s a manual copy of GitHub that drifts the moment anyone touches the repo directly.
• A github kanban board with two-way label sync makes columns a view of GitHub, not a copy—so the board and the code can’t disagree.
• Two-way sync is the essential feature: writing labels back to GitHub is what kills the daily reconciliation tax.
• Consolidating onto GitHub also unifies your workflow vocabulary, keeps comments with the PR, and lets roles replace free-for-all editing.

If your Kanban board and your GitHub repo keep telling different stories, KazTrack renders your workflow as a github-native board where labels sync both ways—worth trying before you drag one more card by hand.