5 Kanban Tools I’ve Actually Used With Agile Teams (And Why I Keep Switching)

The Real Problem With Picking a Kanban Tool for Your Team

You don’t have a discovery problem. There are easily a dozen well-marketed Kanban tools ranked in every “best of” list, each with a polished landing page, a comparison table that conveniently wins every column, and a 14-day trial that requires a credit card. The actual problem is that evaluating even three of them properly — setting up a real board, importing backlog items, wiring up an integration, and getting your team to actually use it for a week — takes time you don’t have between sprints. I’ve been through this cycle twice, once at a 6-person startup and once migrating a 15-person engineering org off Jira, and both times I wasted at least a month on tools we ended up dropping.

Here’s the thing the marketing pages are careful not to highlight: the features that actually matter for Kanban — WIP limits, automation rules, and API access — are almost always locked behind a paid tier. And the pricing pages are written to obscure this. You’ll see “automation” listed under the free plan, click through, and discover it means 100 actions per month across your entire workspace. That’s gone by day three if you’re doing daily standups with card transitions. WIP limits are even worse — Linear doesn’t have native WIP limits at all without workarounds, Trello’s Power-Ups gate them depending on your plan, and Asana’s implementation is so buried in settings that half my team didn’t know it existed for two months. The API situation follows the same pattern: most tools advertise REST or GraphQL access, but rate limits, missing endpoints for board-level data, and broken webhook payloads are things you only discover when you’re actually building an integration.

This guide is specifically for small-to-mid engineering teams — roughly 3 to 25 people — who are running sprints or continuous flow Kanban without a dedicated project management admin babysitting the tooling. If your org has someone whose full-time job is configuring Jira workflows, this isn’t for you. I’m writing for the tech lead who’s also the one setting up the board, the senior dev who inherited a half-configured Monday.com workspace, and the startup CTO who needs something the whole team will actually open without being nagged. None of these tools need to handle 200 projects, SSO provisioning, or SOC 2 audit logs. They need to get out of the way and let your team ship.

• WIP limits matter more than visual polish. A tool that looks great but can’t enforce column limits will let your “In Progress” column silently become a graveyard of half-finished work.
• Automation is only useful if the free tier isn’t capped at nothing. Moving a card to “Done” and triggering a Slack notification shouldn’t require a $20/user/month upgrade.
• API access should be table stakes. If you can’t pull board state into a script or push updates from your CI pipeline without jumping through OAuth hoops, the tool creates silos instead of reducing them.
• Mobile apps are not optional. Async teams check boards from phones. A broken mobile experience means the board data goes stale and standups turn into update sessions instead of blocker discussions.

One more thing before we get into the actual tools: don’t evaluate these in isolation. Your Kanban board doesn’t exist in a vacuum — it connects to your PR workflow, your Slack workspace, your incident tracker, and probably your billing system if you’re tagging work to clients. For a broader look at tools across your entire stack, check out our guide on Essential SaaS Tools for Small Business in 2026. Stack fit is genuinely a tiebreaker here — I switched my team from ClickUp to Linear largely because the GitHub integration was half the clicks and the API responses were consistent enough to actually build on.

Quick Comparison: Pricing, Free Tier, and Biggest Dealbreaker

Before I break down each tool’s gotchas, here’s the comparison table you actually want to screenshot before your next planning meeting. One caveat I’ll repeat later: pricing pages change constantly, sometimes mid-quarter. Treat this as directional, not contractual.

Tool	Free Tier Limits	Paid Starting Price	WIP Limit Support	API / CLI	Biggest Dealbreaker
Linear	Up to 250 issues	~$8/user/month	No native WIP limits	Excellent REST + GraphQL API	Hard 250-issue ceiling will surprise you faster than you think
Jira	Up to 10 users	~$8.15/user/month	Yes, but buried	REST API, no official CLI	Atlassian ecosystem lock-in compounds over time
Trello	Unlimited cards, 10 boards	~$5/user/month	Via Power-Up only	REST API, community CLIs	Power-Ups replace what should be built-in features
Notion	Unlimited pages, limited history	~$10/user/month	Not really — it’s a database filter	REST API, no CLI	Kanban is bolted on top of a database — it shows
GitHub Projects	Free with any GitHub plan	Included in Team/Enterprise	Manual only, no enforcement	GraphQL API, gh CLI	Workflow automation lags significantly behind Jira and Linear

The thing that caught me off guard with Linear was hitting 250 issues on a mid-sized side project in about six weeks. A sprint’s worth of tasks, sub-tasks, and bug reports adds up fast. You upgrade or you archive, and archiving issues to stay under the limit is exactly the kind of friction that kills adoption on small teams. The API, though, is genuinely good — you can pull board state with a clean GraphQL call and pipe it into a Slack digest, a custom CLI tool, or whatever reporting layer your stakeholders actually check:

curl -X POST https://api.linear.app/graphql \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "{ issues(filter: { state: { name: { eq: \"In Progress\" } } }) { nodes { title assignee { name } } } }"}'

Jira’s WIP limit support is technically there, but finding it feels like a scavenger hunt the first time. You navigate to Board Settings → Columns, then set min/max values per column — it’s not surfaced anywhere during initial board setup. I’ve watched three separate teams onboard to Jira’s free tier, skip this entirely, and then wonder why their “In Progress” column routinely holds 14 items. The real dealbreaker, though, isn’t the UI friction — it’s what happens 18 months in when your team is deep in Confluence, Jira Service Management, and Atlassian Access for SSO. Switching costs compound quietly until leaving feels impossible.

Trello’s free tier is one of the most genuinely usable free plans in this category — unlimited cards on up to 10 boards covers a lot of real teams. But the Power-Up model is where I get frustrated. WIP limits require a third-party Power-Up like WIP for Trello or Corrello. Recurring cards need another Power-Up. Custom fields, another one. Each adds a separate authentication flow, a separate settings panel, and a separate potential point of failure. I switched away from Trello for a client project specifically because I was managing five Power-Up integrations instead of the actual work.

Notion is the most honest entry to categorize: it is not a Kanban tool. You can create a database, add a Status property, and switch to Board view — and it looks like Kanban. But there’s no concept of WIP enforcement, no cycle time tracking, and no way to set column policies. Every “card” is actually a full Notion page, which is powerful for documentation but weird for a quick task. I use Notion for project wikis and async decision logs alongside a real Kanban board. Using it as the board itself means accepting that you’re trading workflow correctness for flexibility, and that trade bites you when a sprint review turns into a philosophy debate about database filters.

GitHub Projects gets a free pass if your code already lives on GitHub — there’s no additional cost argument to make. The gh CLI has project support that’s steadily improving:

# List all items in a project
gh project item-list 1 --owner YOUR_ORG --format json

# Add an issue to a project board
gh project item-add 1 --owner YOUR_ORG --url https://github.com/your-org/repo/issues/42

The gap shows up in automation. Jira’s automation rules and Linear’s workflow states are genuinely sophisticated — you can auto-move issues based on PR status, block transitions, enforce required fields. GitHub Projects’ built-in automation is limited to a handful of preset triggers (issue opened → add to board, PR merged → mark done). Anything beyond that means writing GitHub Actions workflows yourself, which is doable but is real maintenance overhead your team now owns. If your team is small and code-centric and the workflow is simple, it’s a great default. If you need policy enforcement at scale, you’ll hit the ceiling fast.

One honest note before you commit to anything: every price listed here reflects what I verified at writing time, but these tools reprice, restructure tiers, and quietly move features between plans regularly. Go check the current pricing page directly — and specifically look for what happens to your data if you downgrade, because that’s almost never explained prominently during signup.

Tool 1: Linear — What I Use for My Own Projects

I Switched from Jira in 2022 and My Team Has Never Asked to Go Back

The switch happened after a particularly painful sprint planning session where someone spent 20 minutes trying to explain why our Jira board had 47 statuses across 3 projects that nobody maintained. I spun up a Linear workspace that same afternoon, imported the backlog overnight, and had the team running in it by the next standup. That speed of setup isn’t a marketing claim — the actual flow is: create workspace, invite engineers via email or Google SSO, pick your first project, and your Kanban board is immediately usable. No scheme configuration, no workflow editor, no “contact your admin.” For teams under 20 engineers, this matters more than any individual feature.

The thing that tripped me up first was the distinction between the Board view and Cycles. They look similar but model completely different things. The Board is your running Kanban — issues flow through Todo → In Progress → Done continuously. Cycles are time-boxed buckets, Linear’s version of sprints, where you explicitly pull issues in at the start of a cycle and review completion at the end. If you use Cycles as your primary workflow and ignore the Board, you’re doing Scrum with a Kanban-flavored UI. If you live in the Board and only use Cycles for reporting, that’s closer to pure Kanban. I run both: the Board is my daily driver, Cycles give me a two-week rhythm for stakeholder updates. Understanding this distinction saves you a week of confusion where your team asks “wait, where do I put this issue?”

Now the rough edge I want you to know before you commit: WIP limits don’t exist as a native feature. On a real Kanban board, limiting work in progress is the entire point — it’s not a nice-to-have. In Linear, you can’t set “max 3 issues in In Progress” and get a visual warning when someone pushes a fourth. You enforce this through team conventions (“we verbally agreed to max 3 per person”), or you build around it with the API. Speaking of which, the GraphQL API is genuinely solid. Here’s a real query to pull all in-progress issues for a team:

curl -X POST https://api.linear.app/graphql \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "{ issues(filter: { state: { type: { eq: \"started\" } } }) { nodes { id title assignee { name } } } }"
  }'

You could build a Slack bot that fires when a team member has more than 3 open issues in “started” state. I’ve seen teams do exactly this. It’s a workaround, not a solution, but it’s a functional one. The API key lives at linear.app/settings/api and the rate limit is 1,500 requests per hour on the free tier — more than enough for automation scripts. One thing to clear up: there is no npm install -g @linear/linear CLI package that does what you’d expect. There’s an official JS SDK (npm install @linear/sdk) for building integrations, but no terminal tool for day-to-day issue management. If you want CLI access, you’re writing scripts against the GraphQL API yourself.

• Pricing reality: Free tier supports up to 250 issues — you’ll hit that within 2 months on an active project. The Plus plan is $8/user/month (billed annually), which unlocks unlimited issues, GitHub integration with auto-closing issues from PRs, and priority support.
• GitHub sync is actually useful: branch names prefixed with the issue ID (e.g., feat/ENG-142-add-oauth) automatically link PRs to issues. Linear detects this and moves the issue to “In Review” when a PR opens. Zero configuration required.
• No time tracking: if your project manager or client needs logged hours, you’re adding Harvest, Toggl, or something else. Linear has no concept of time estimates beyond story points, and no actuals tracking at all.

Where Linear loses cleanly: the moment you try to run a non-engineering team on the same board — marketing, design, ops — it gets uncomfortable fast. The entire mental model is built around software development cycles. There’s no way to represent a content calendar, a campaign launch checklist, or a vendor approval workflow without it feeling like you’re fighting the tool. I tried running our design team in Linear for six weeks. They tolerated it. When I moved them to a dedicated tool and integrated via the API, everyone was happier. Use Linear for your engineering team specifically, and integrate outward rather than expanding inward.

Tool 2: Jira — Still the Standard, Still Annoying

The Lock-In Is Real — And It’s Probably Already Got You

If your org runs Confluence for docs and Bitbucket for version control, you’re not really choosing Jira — you’re just acknowledging reality. Migrating off Jira when you’ve got Confluence spaces linked to every epic, Bitbucket pipelines triggering issue transitions, and years of velocity data baked into dashboards means you’re not switching tools, you’re planning a migration project that will outlast your quarterly roadmap. I’ve watched teams spend three months “evaluating Linear” while still living in Jira. The switching cost isn’t the license fee, it’s the institutional memory and integrations you can’t easily export. If you’re deep in the Atlassian stack, Jira stays.

Setting Up a Kanban Board: Pick the Wrong Project Type and You’re Starting Over

The thing that caught me off guard the first time I set up Jira for a new team was the project type selector. When you create a new project in Jira Software, you’ll see Scrum and Kanban as options. Pick Scrum by accident — which is easy to do because it’s listed first and honestly looks like the “full-featured” option — and you get sprint-based boards by default. There’s no clean toggle to switch a Scrum project to a Kanban board after the fact. You can hack around it, but at that point you’re fighting the tool instead of using it. The fix is simple: on project creation, select Kanban under “Project template.” Your board will then be flow-based with a continuous backlog rather than sprint buckets.

New Project → Select "Scrum" ❌ — you get sprints, velocity charts, sprint planning
New Project → Select "Kanban" ✅ — you get a flow board, cumulative flow diagram, no sprints

WIP Limits: Where Jira Promises More Than It Delivers

Setting WIP limits sounds straightforward: Board Settings → Columns → enter a number in the “Max” field for each column. And for a flat board with no swimlanes, it actually works. The board turns the column header orange when you’re over the limit — not a hard block, just a visual warning, which is the right call for a Kanban tool. But add swimlanes — which most teams do, either by assignee or by epic — and the WIP limit logic gets weird. Jira counts issues per column across all swimlanes combined, not per swimlane. So if your WIP limit is 3 and you have two swimlanes with 2 issues each, Jira flags it as over-limit even if both swim lanes are perfectly reasonable. I’ve seen this confuse teams into removing WIP limits entirely, which defeats the point. There’s no native fix; it’s a documented limitation that Atlassian has been sitting on for years.

Automation That Actually Works: Issue Transitions → Reviewer Assignment + Slack

Jira’s automation engine is genuinely one of the better parts of the product. The rule I keep coming back to: when an issue transitions to “In Review,” auto-assign a reviewer and post a Slack message with a direct link. Here’s what the rule looks like in the automation editor:

• Trigger: Issue transitioned → To status: “In Review”
• Action 1: Assign issue → specific user or smart value like {{issue.reporter}}‘s designated reviewer
• Action 2: Send web request → POST to your Slack webhook URL

The Slack payload body looks like this:

{
  "text": "Review needed: <{{issue.url}}|{{issue.key}} - {{issue.summary}}> assigned to {{issue.assignee.displayName}}"
}

I’ve run this rule across multiple projects and it’s reliable — it doesn’t silently fail the way some of Jira’s older notification configs do. Slack gets the message within a few seconds of the transition. The automation builder UI is drag-and-drop, lives under Project Settings → Automation, and the free tier includes 100 rule runs per month per user, which is enough for most small teams. Standard and Premium plans remove that cap.

The Honest Trade-off: Power vs. Daily UX Tax

Jira is powerful enough to model almost any workflow you can describe. Custom fields, issue hierarchies (epics → stories → subtasks → and now “child issues” depending on your plan), release tracking, portfolio views, compliance audit logs — it’s all there. But the UX is genuinely exhausting. Navigating between the project board, the backlog, issue detail views, and board settings involves more clicks than it should. Filter JQL is expressive but nobody should have to write project = MYPROJECT AND status = "In Progress" AND assignee = currentUser() just to see their own active work. On Jira’s Cloud Standard plan you’re paying $8.15/user/month (as of 2024 pricing). Premium runs $16/user/month and adds advanced roadmaps and admin controls. You’re not paying for elegance — you’re paying for depth and compliance features that nobody else bundles as neatly.

When Jira Is Actually the Right Answer

• Large orgs with cross-team dependencies: Jira’s cross-project linking and portfolio tracking handles 10 teams better than any lightweight tool I’ve used.
• Compliance-heavy environments: SOC 2, ISO 27001 auditors want to see audit logs and access controls. Jira has them. Trello doesn’t.
• Heavy reporting needs: If your VP of Engineering needs sprint velocity, cycle time, and cumulative flow in a weekly report, Jira’s built-in reports cover it without custom tooling.
• You’re already paying Atlassian: If Confluence is in the contract, Jira is probably already bundled or close to it. Don’t add a second tool to solve a problem the first one already handles.

If none of those apply — if you’re a startup, a small team, or a team that values speed of setup over depth of configuration — Jira will feel like overhead from day one. But if they do apply, Jira’s the pragmatic choice, not the exciting one.

Tool 3: Trello — Dead Simple, Until You Need More

Trello is the only tool on this list where I’ve watched a product manager, a designer, and a client from a non-technical company all get oriented in the same 10-minute onboarding call — and every single one of them was moving cards around confidently before I finished explaining the board. That’s not a small thing. Most agile tooling has a learning cliff disguised as a learning curve, and Trello genuinely doesn’t.

The Kanban mapping is dead obvious: Lists are your columns (Backlog, In Progress, Review, Done), Cards are your issues, Labels handle priority or type (I usually set up red/yellow/green for urgency and blue/purple for bug vs. feature). You can have a fully functional Kanban board running in under five minutes. The problem is what happens after that, when your process gets slightly more complex.

WIP Limits: The Ugly Workaround

Trello has no native WIP limit enforcement. Zero. You can put a number in your column title like In Progress (max 3) and rely on your team’s discipline — which, honestly, works better than you’d expect for small teams — but there’s no system-level block. The “official” workaround is the Card Repeater Power-Up or third-party tools like Placker. Card Snooze is another Power-Up people reach for, but using it to simulate WIP limits is genuinely duct tape. It’s not what it’s built for, and it shows. If WIP limit enforcement is non-negotiable for your workflow, Trello is already losing the argument.

Butler Is the Best Thing Trello Has

Butler (Trello’s built-in automation) surprised me the first time I actually used it. Simple rules like “when a card is moved to Done, add a Done date and archive after 7 days” or “when a card is labeled Urgent, move it to the top of In Progress” work cleanly and take about 90 seconds to configure. No YAML, no webhook setup, just a rule builder that makes sense. The free tier includes 250 Butler runs per month per workspace — enough for a small team’s routine automation. Where it falls apart: conditional logic chains. If you’re trying to build something like “if card has label X AND is in column Y AND has a due date within 3 days, then notify member Z and move to Expedite” — you will feel the ceiling fast. That kind of logic belongs in Zapier or Make, not Butler.

The Reporting Situation Is Pretty Bad

I’m going to be blunt: Trello’s reporting is basically nonexistent out of the box. There’s no burndown chart. No cycle time tracking. No cumulative flow diagram. You can install the Corrello Power-Up (paid, starts around $15/month per board) to get actual Kanban metrics, but at that point you’re bolting on a separate product. The free Trello dashboard view shows card counts per list, which is about as useful as counting sticky notes. If your team or stakeholders need velocity data or sprint retrospectives backed by numbers, plan for the extra tooling cost from day one — don’t assume you’ll figure it out later.

Sub-tasks: Checklists Are Fine, Until They’re Not

Trello gives you checklists inside cards instead of true sub-tasks. For a lot of workflows this is fine — a card for “Build login flow” with checklist items for OAuth setup, form validation, error states, and tests covers most use cases. The problem is checklists don’t have assignees, due dates, or their own comments. The moment a checklist item needs to be owned by a different person or tracked independently, you’re either creating a separate card (and losing the parent relationship) or living with a broken mental model. Linear, Jira, and ClickUp all handle this better. Trello doesn’t pretend it’s solving this problem — it just doesn’t solve it.

When to Actually Pick Trello

• Small teams (2–5 people) where process overhead would cost more than it saves
• Non-technical stakeholders who need to move cards themselves without a training session
• Short-run projects — marketing campaigns, event planning, client deliverable sprints in the 2–4 week range
• Side projects where you want to track work without managing a tool that manages your work

Trello’s free tier is genuinely usable — unlimited cards, 10 boards per workspace, and one Power-Up per board. The Standard plan at $5/user/month (billed annually) unlocks unlimited Power-Ups and custom board backgrounds, which matters once you’re running Butler rules and need Corrello or a WIP limit Power-Up alongside it. Where I’d draw the line: the moment your team starts asking “can we see how long cards are staying in each column?” — that’s the signal Trello has hit its ceiling for your use case.

Tool 4: Notion — A Database Pretending to Be a Kanban Board

You’re Already Using Notion for Docs — That’s Exactly the Trap

The pitch goes like this: “We’re already paying for Notion, our docs are in there, our wikis are in there — let’s just run our sprints there too.” I’ve seen this decision made in a 10-minute Slack thread by three people who’ve never actually built a Kanban board in Notion. The consolidation logic is sound. The outcome is usually a board that looks functional for two weeks, then quietly gets abandoned in favor of a shared spreadsheet nobody mentions out loud. Notion is a genuinely excellent tool. It’s just not a project management tool with Kanban bolted on — it’s a database tool where you can simulate a Kanban board if you’re willing to accept what you’re giving up.

How to Actually Set One Up (It Does Work)

To be fair to Notion, the setup is clean. Create a new page, hit /database and select Table — Full page. Add a property called Status with type Select, then create your options: Backlog, In Progress, In Review, Done. Now hit the Add a view button at the top left, choose Board, and group by Status. That’s it — you have a working Kanban board. Cards can hold text, images, embeds, files, checkboxes, relations to other databases. For a content team tracking blog posts with draft copy, cover images, and publish dates all on the same card, this is genuinely useful. The mixed-media card is where Notion beats every dedicated PM tool on this list.

What You’re Actually Giving Up

Here’s where it falls apart for any team running real agile cycles. There are no WIP limits. You cannot cap a column at 3 items and get a warning when a fourth card moves in — that concept doesn’t exist in Notion’s Board view. There’s no sprint mechanism at all; you’d fake it with a Sprint select property and filter views, which works until someone forgets to update the property and your “current sprint” board silently includes week-old tickets. Automations exist on Notion’s Business plan ($18/user/month billed annually as of mid-2025), but they’re basic: “when status changes to Done, send a Slack message.” Compare that to Linear’s cycle automation or Jira’s workflow rules with conditional branching and you’ll feel the gap immediately. Velocity tracking, burndown charts, cumulative flow — none of it exists without building it yourself, probably in a connected database, probably in a way that breaks when someone renames a status option.

The Performance Cliff at 40+ Cards

This one caught me off guard. Notion databases get sluggish when a single board view has more than 40 active cards. Not catastrophically slow, but noticeably laggy — drag-and-drop has a half-second delay, filters take a moment to apply. This is a known behavior with large Notion databases, and the community workaround is to archive completed cards into a separate database via a relation. That’s a legitimate fix, but now you’re maintaining two databases and a relation schema to keep a basic board functional. If your team ships fast and your board accumulates cards quickly, budget time for this plumbing. Linear or Jira don’t have this problem at typical team scale.

Where Notion Actually Wins

• Design teams managing deliverables with attached mockups, Figma embeds, and client feedback directly on the card
• Marketing sprints where each card is a campaign asset with copy, visuals, and publish metadata all in one place
• Content calendars — Notion’s Board view with a date property is the best content calendar setup I’ve used short of a dedicated tool
• Small teams (under 6 people) that are already deep in Notion for documentation and don’t need sprint tracking, velocity metrics, or WIP enforcement

The filter system is genuinely good — you can build filtered views per assignee, per sprint tag, per content type, and save them as separate views on the same database. That part scales well. But the moment your team asks “can we see our velocity over the last three sprints?” or “why does In Progress always have 9 cards?”, Notion has no answer. If your team lives in Notion, bills in Notion, and documents in Notion, and your “agile process” is more kanban-flavored task management than strict sprint discipline — stay in Notion. If you’re running actual two-week cycles with retrospectives and capacity planning, you’ll outgrow this board on the first sprint review.

Tool 5: GitHub Projects — Underrated If You Live in GitHub

If Your Whole Stack Lives in GitHub, This Is the Obvious Answer You’re Probably Ignoring

The context-switching cost of jumping between GitHub and a separate project management tool is real and underappreciated. You’re reviewing a PR, you spot a bug, and now you have to open Jira, find the right project, create a ticket, copy a link back into the PR comment — and you’ve just spent four minutes on overhead that should have been thirty seconds. If your issues, PRs, code reviews, and CI runs all live in GitHub, GitHub Projects is the zero-friction choice. I switched one of my open source projects to it purely to eliminate that tab-hopping, and I haven’t looked back.

If you tried GitHub Projects two or three years ago and hated it, that’s valid — v1 was genuinely bad. The current version (Projects v2, rolled out through 2022-2023) is a different product. You get a real Board view, a Table view, a Roadmap view, custom fields (text, number, date, single select, iteration), and cross-repo project support. Setting up a Kanban board takes about 90 seconds: go to your repo, hit the Projects tab, click New project, and choose the Board template. Your existing open issues auto-populate into the “Todo” column. That’s it. No CSV imports, no third-party syncing, no “connect your GitHub account” OAuth dance.

The automation story is where GitHub Projects gets genuinely interesting for dev teams. You can move cards between columns automatically when PR status changes, without touching any paid tier. Here’s a real workflow file that closes an issue and moves it to “Done” when a linked PR merges:

name: Move issue to Done on PR merge

on:
  pull_request:
    types: [closed]

jobs:
  move-card:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v7
        with:
          github-token: ${{ secrets.PROJECT_TOKEN }}
          script: |
            const issueNumber = context.payload.pull_request.body.match(/#(\d+)/)?.[1];
            if (!issueNumber) return;
            // Use GraphQL to update project item status to Done
            // Full mutation available at: docs.github.com/en/graphql/reference/mutations#updateprojectv2itemfieldvalue

You’ll need a classic personal access token (PAT) with project scope stored as a repo secret — PROJECT_TOKEN in the example above. The GraphQL mutation to actually move the card is about 10 lines. The GitHub docs have the full example under Automating Projects using Actions. The thing that caught me off guard: you need the project’s internal node ID, which isn’t the number you see in the URL. Run this once to grab it:

gh api graphql -f query='
{
  organization(login: "your-org") {
    projectV2(number: 5) {
      id
    }
  }
}'

Now for the honest rough edges, because there are real ones. There is zero WIP limit UI. None. You cannot set a column cap. If you want WIP limits enforced, you’re writing your own GitHub Action to check column count and post a comment, which is a weekend project in itself. Custom fields exist but they’re clunky — adding an “effort” field means clicking into every issue individually to set it, there’s no bulk edit in the board view. The Roadmap view is functional but basic; you can set start/end dates on iterations, but don’t expect the drag-to-resize timeline experience you get from Linear or Jira Advanced Roadmaps. And the reporting is essentially non-existent — no velocity charts, no cumulative flow diagrams, no burndown. If your team’s retros depend on sprint metrics, you’ll be exporting to CSV and building your own charts.

GitHub Projects wins in three specific situations: open source projects where contributors already live in GitHub and adding Jira access creates a barrier to contribution; small dev teams (think 2-6 engineers) who don’t need portfolio-level reporting and genuinely can’t justify $8-10/seat/month for another SaaS tool on top of their existing GitHub subscription; and orgs running GitHub Enterprise where Projects is already included and procurement for new SaaS takes three months and a security review. If you’re a solo developer or a scrappy team shipping fast, this is probably good enough — and “good enough inside the tool you’re already in” beats “fully-featured in a tab you never open.”

When to Pick What: Match the Tool to Your Actual Situation

Stop Shopping for Tools and Just Match the Situation

The most expensive mistake I see teams make isn’t picking the wrong tool — it’s spending three weeks evaluating options when the right answer is obvious from the team size alone. Here’s the decision tree I actually use when someone asks me what to pick.

Solo dev or 2-person team: Trello free tier or GitHub Projects

Trello’s free tier gives you unlimited cards, 10 boards per workspace, and basic automation. That’s enough. I ran a side project with a contractor for eight months on the free tier and never hit a wall. GitHub Projects is the other real option here — and honestly, if you’re already pushing code to GitHub, the friction of keeping work items in a separate tool will quietly kill your process. GitHub Projects lets you auto-populate issues as cards and filter by label, assignee, or milestone right out of the box. Zero extra logins, zero extra tab. The gotcha: GitHub Projects’ Kanban view is barebones compared to Trello. No card aging, no WIP limits without a workaround, no color labels without a browser extension. But for two people moving fast, that simplicity is a feature.

Engineering team of 5-25, moving fast: Linear

I switched to Linear after six months of fighting Jira’s load times and I genuinely did not expect the UI speed to change how often I updated tickets. But it does. Linear opens in under a second on a cold load. Keyboard shortcuts work consistently. C creates an issue, G then I takes you to your inbox. The cycle time that used to eat five minutes of morning standup prep now takes thirty seconds. Linear’s pricing sits at $8/user/month on the Standard plan (check their site for current rates — they’ve adjusted before). The honest trade-off: Linear’s reporting is decent but not deep. If your VP of Engineering wants burndown charts with custom date ranges and cross-project rollups, you’ll hit the ceiling. For most fast-moving product teams though, the Cycles feature (Linear’s version of sprints) is all you need.

Enterprise already inside Atlassian: Jira, full stop

I’ve helped two teams migrate away from Jira and both times it cost more pain than staying would have. Your CI/CD pipelines probably have Jira ticket IDs baked into commit hooks. Your PMs have years of velocity data in Jira dashboards. Your Confluence docs link to Jira epics. Unless developers are actively rage-quitting over the tool — not just complaining, but actually leaving — the switching cost isn’t worth it. Jira’s Standard plan is $7.75/user/month for cloud (billed annually, verify current pricing on Atlassian’s site). The thing that catches teams off guard: Jira’s automation rules are genuinely powerful once you learn them, but the rule builder interface is hostile. Budget an afternoon to get your first workflow automation right. Once it’s running, it runs.

Mixed team sharing one board (eng + design + marketing): Notion with Board view

Notion isn’t a great project management tool. I’ll say that clearly. But it’s the only tool where a designer can embed a Figma file, a marketer can write a campaign brief, and an engineer can paste a code snippet — all in the same place, with a Kanban board sitting one click away from that content. The Board view in Notion is filtered database properties, which means you can have one master database and multiple views: one for engineering sprints, one for marketing calendar, one for design handoffs. The limitation to accept upfront: there’s no real sprint planning, no cycle time tracking, and automation is limited to simple status triggers unless you pay for Notion’s higher tiers or wire in Zapier. If your team is cross-functional and you’re trying to reduce tool sprawl, Notion earns its place. If you’re an engineering-only team, don’t use it for Kanban — you’ll regret it within a month.

Open source project or public repo: GitHub Projects, no debate

Contributors already have GitHub accounts. External contributors do not want to create a Linear or Trello account to pick up a good-first-issue. GitHub Projects is public, linkable, and lives next to your code. You can reference a project card directly from a PR with a closing keyword: Closes #42 in a PR description auto-moves that issue to Done when the PR merges. For open source, that automatic hygiene is worth more than any fancy reporting feature. Set up a simple three-column board — Backlog, In Progress, Done — label your issues clearly, and let contributors self-assign. That’s the whole system.

You need real reporting and custom workflows: Jira or Linear paid tier

If someone in your organization needs to answer “what’s our average cycle time per engineer over the last quarter” or “show me all blockers across four active projects filtered by team,” you’re in paid-tier territory. Linear’s paid tier unlocks advanced analytics and custom views. Jira’s Premium tier ($15.25/user/month on cloud — check Atlassian for current pricing) adds roadmaps, capacity planning, and advanced automation with cross-project rules. The thing I didn’t expect when first using Jira Premium’s roadmaps: child issue rollup is automatic, but it only works cleanly if your epic-story hierarchy is consistent. One team setting up epics differently than another will break the rollup. That’s a team discipline problem, not a Jira bug — but you’ll discover it at the worst time, usually right before a board review.

The Things None of Them Handle Well

Let’s start with WIP limits because this one genuinely surprised me when I moved from a physical Kanban board to digital tools. Every tool in this list lets you display a WIP limit. Almost none of them actually enforce one. Jira will show you a red badge when you’ve exceeded the limit on a column. Linear lets you set a number. ClickUp has the field. But in every case, someone can drag another card into that column and nothing stops them. No hard block, no confirmation dialog, nothing. You end up in the same place you’d be without limits — relying on the team to honor the constraint culturally. If your team already has that discipline, great, the tool is redundant. If they don’t, the tool won’t fix it. The only tool I’ve seen do this with any teeth is Kanbanize (now Businessmap), and that’s not in most people’s budget at $179/month for small teams.

Cross-team dependencies are where every single one of these tools quietly gives up. Trello has “linked cards” via Power-Ups. Jira has the “blocks/is blocked by” link type that looks great in demos and falls apart in practice because the other team is using a different board, their ticket priorities don’t align with yours, and nobody checks the dependency view anyway. Linear’s dependency graph is the cleanest I’ve used — genuinely useful UI — but it only works if both teams are on Linear. The real workflow ends up being: ticket gets blocked, someone pastes the link in Slack, a thread starts, someone @-mentions the other team, and two days later the blocker is resolved and nobody updates the ticket. I’ve watched this happen at every company I’ve worked at regardless of the tool. Stop expecting software to solve what is fundamentally a communication and priority alignment problem between teams.

Time tracking is a gap that none of these tools close without upselling you. Here’s the actual situation across the board:

• Trello: No native time tracking. Toggl has a free Power-Up that’s genuinely decent — one-click timer from the card. Harvest also has one. Both work fine for freelancers.
• Jira: Has a “Log Work” field built in, but it’s manual-entry only. Tempo Timeplanner starts at $10/user/month on top of your Jira costs if you want automatic tracking or reporting.
• ClickUp: Has time tracking in the free plan, but the reporting is locked behind Business tier at $12/user/month. The free version tracks time and shows you nothing useful about it.
• Asana: Zero native time tracking. Harvest and Toggl both integrate cleanly via their Chrome extensions — you’ll barely notice the seam.
• Linear: No time tracking at all. Not even a field. Budget for Toggl ($9/user/month on Starter) if your team needs it.

My default recommendation: just use Toggl Track’s free tier for teams under 5 people, or pay the $9/user for Starter if you need reporting. It integrates with everything via browser extension and doesn’t care which project management tool you’re using. Don’t contort your PM tool choice around time tracking — they’re separate problems.

The mobile situation is honestly embarrassing across the board, and I say that having used all five of these apps on my phone during on-call rotations when I needed to move a card or update a status. Jira Mobile is slow, the board view is cramped, and half the time I’d open a ticket and the custom fields wouldn’t load. ClickUp’s mobile app has everything the desktop version has, which sounds good until you realize that’s the problem — it’s overwhelming and the navigation doesn’t translate to a small screen. Asana’s app is clean but limited; you can comment and mark things done, but trying to manage a sprint from it feels like trying to write code on a calculator. Linear’s app is the most thoughtfully designed for mobile use but still not something I’d want to do real triage from. Trello is the honest winner here — the card-based layout genuinely works on a phone, drag-and-drop actually functions, and the app loads fast. If mobile access is a real requirement for your team (field workers, on-call rotations, anyone not glued to a laptop), Trello’s UX advantage here is meaningful and none of the others have closed the gap.

---

---