Personal Kanban for Developers: A Practical Setup

Personal Kanban for developers is a simple visual system for answering three questions: what could I work on, what am I working on now, and what is blocked or waiting? The point is not to recreate Jira for one person. The point is to protect attention.

Most developers already have too many boards: Jira sprint boards, GitHub project boards, GitLab issues, Linear views, Trello boards, and maybe a personal to-do list. A personal Kanban board should be smaller than all of them. It should show the work that competes for your focus today. For the wider workflow around focus, issue trackers, and deep work, see the Developer Productivity Guide.

Why personal Kanban works for developers

Software work is full of invisible work in progress.

You start a bug, pause to review a PR, answer a question in chat, check CI, return to the bug, notice a failing test, then open a second issue. By lunch, you feel busy but cannot explain the shape of the day.

Personal Kanban helps because it makes work states visible:

• Backlog: possible work, not a commitment.
• Ready: work you can start without more thinking.
• Doing: your current attention.
• Waiting: blocked by a person, build, review, or decision.
• Review: work done by you but not yet merged, shipped, or closed.
• Done: completed work, useful for shutdown and weekly review.

That visual separation matters. A flat list says everything is equally available. A board says, “This is active, this is blocked, this can wait.”

The minimum developer board

Start with six columns:

This is enough for most individual developers.

Avoid starting with columns like “Analysis”, “Design”, “Implementation”, “Testing”, “QA”, and “Deploy” unless each column changes what you do next. If your personal board looks like an enterprise process map, you will stop using it.

Add WIP limits before you add features

The power of Kanban is not dragging cards. It is limiting work in progress.

Use these personal WIP limits:

• Doing: 1 card
• Waiting: 3 cards
• Review: 3 cards
• Ready: 5 cards

The limits are intentionally small. If “Doing” has four cards, you are not doing four things. You are switching between four unresolved contexts. That means your board is telling the truth, but your workflow is leaking focus.

When a column hits its limit, stop pulling new work. Clear or renegotiate existing work first.

Examples:

• Doing is full? Finish, pause, or explicitly move the task to Waiting.
• Waiting is full? Follow up, close stale blockers, or decide what no longer matters.
• Review is full? Review or ask for review before starting more code.
• Ready is full? Stop grooming the backlog and start executing.

Turn issue trackers into inputs, not masters

Your team issue tracker is a source of truth for shared work. Your personal Kanban board is a source of truth for your attention.

Do not mirror every assigned ticket. Pull only the items that need personal action.

Good personal cards:

• “Investigate flaky sync test”
• “Review Nora’s PR about calendar auth”
• “Write migration notes for release”
• “Follow up on API rate limit question”

Bad personal cards:

• “Sprint 42”
• “Backend epic”
• “Refactor project”
• “Work on Jira”

Each card should represent a next action or a small cluster of actions, not a whole project.

If you use Super Productivity, connect Jira, GitHub, or GitLab and pull issues into your local task list. Then use your personal board to decide what is actually active today. That keeps the team tool intact while giving you a private execution layer.

How to size cards

A personal Kanban card should usually fit inside one focused session.

Use this sizing rule:

• 15 minutes: admin, small review, quick reproduction
• 25 minutes: focused bug investigation or small implementation
• 45 minutes: deeper coding, writing, or review
• 90 minutes: only for genuinely complex work with a checkpoint

If a card is larger than 90 minutes, split it.

Instead of:

• “Implement calendar integration”

Use:

• “List calendar auth requirements”
• “Create OAuth setup task”
• “Render events in planner view”
• “Handle expired token state”
• “Write docs for calendar permissions”

Small cards reduce task paralysis because the next move is visible.

A developer-specific weekly rhythm

Use the board in three lightweight loops.

Morning planning

Spend five minutes:

1. Move at most five cards into Ready.
2. Pick one Doing card.
3. Add time estimates.
4. Hide the rest.

This prevents backlog browsing from becoming the first procrastination loop of the day.

During work

Move cards only when state changes:

• Ready to Doing when you start.
• Doing to Waiting when blocked.
• Doing to Review when the PR is open.
• Review to Done when merged, accepted, or closed.

Do not use the board as a diary. Use it as a control surface.

Shutdown

Spend five minutes:

1. Move finished work to Done.
2. Add a short note to any Waiting card.
3. Pick the likely first card for tomorrow.
4. Clear stale Ready cards.

Shutdown is where the board pays off. Tomorrow starts with less reloading.

Common mistakes

Too many columns

Every extra column asks you to maintain a distinction. If that distinction does not affect behavior, remove it.

No WIP limit

Without limits, Kanban becomes a prettier task list. The board should make overcommitment obvious.

Giant cards

If a card can sit in Doing for a week, it is too large. Split by next action, risk, or deliverable.

Treating blocked work as active

Blocked work belongs in Waiting. Leaving it in Doing keeps your attention attached to something you cannot currently move.

Mirroring the team board

Your personal board should be smaller, more tactical, and more honest about your focus than the team board.

Super Productivity setup

In Super Productivity:

1. Create projects for major work streams, clients, or side projects.
2. Connect issue providers if your work starts in Jira, GitHub, or GitLab.
3. Use the board view for your personal Kanban columns.
4. Keep Today limited to the cards you realistically intend to touch.
5. Add time estimates to every Ready card.
6. Start time tracking when a card moves to Doing.
7. Use task notes to store “where I stopped” before moving a card to Waiting.

This gives you a board, a timer, notes, and external issue context in one place. The fewer tabs you need to reopen, the easier it is to stay with the task.

Next moves

Set up the smallest possible board today:

1. Create Backlog, Ready, Doing, Waiting, Review, and Done.
2. Add five cards, not fifty.
3. Put one card in Doing.
4. Set a 25-minute timer.
5. At shutdown, move cards honestly and pick tomorrow’s first card.

Personal Kanban works when it is boring enough to maintain. Keep it small, limit active work, and let the board show what your attention is actually carrying.

For the broader system around focus, context switching, and issue-tracker workflows, read the Developer Productivity Guide.

Related Resources

• Developer Productivity Guide - the larger workflow around focus and execution
• Stop Tab-Switching: Unify Jira, GitHub, GitLab Tasks - pull external issue work into one place
• Task Estimation for Developers - size cards so your board stays realistic