Kanban Board vs. Todo List: Which Actually Works for Developers? | GritShip Blog | GritShip
WorkflowProductivityDeveloper Tools
Kanban Board vs. Todo List: Which Actually Works for Developers?
Todo lists are simple. Kanban boards are visual. But which one actually helps you ship code? A practical comparison based on how developers really work.
By Imtiaz··30 min read
You've tried both. The todo list that starts clean Monday morning and becomes an anxiety-inducing scroll by Wednesday. The kanban board you set up in a burst of productivity, then abandoned because "it's just a prettier todo list." The truth is both can work — but they fail in different ways, for different reasons, and understanding those failure modes is more useful than any feature comparison.
Developers are particularly bad at choosing between these two because we over-optimize the decision itself. We evaluate seven tools, read three comparison threads on Hacker News, and spend a weekend building a custom Notion template — all to avoid the actual question: which structure matches how I actually work?
The internet doesn't help. Search "kanban vs. todo list" and you'll get articles that either declare kanban the clear winner (written by people selling kanban tools) or call them "equally valid" with no framework for deciding (written by people who haven't used either seriously). Neither helps you make an actual decision.
This isn't a "kanban is better" article. It's a breakdown of where each approach genuinely wins, where it falls apart, and how to pick the right one for what you're building right now. No productivity philosophy. No abstract frameworks. Just a practical comparison based on how developers actually work.
What a todo list actually is
Strip away every app, plugin, and productivity framework, and a todo list is a linear, ordered sequence of tasks. One item follows the next. You work top-down, crossing things off as you go. That's the entire data structure.
Todo lists have survived since the invention of writing because the model is absurdly simple: write down what you need to do, then do it. No columns. No states. No workflow concepts. Just a list.
Developers have a long history with this format. The TODO comment in source code is a todo list embedded directly in the codebase. grep -r "TODO" . is a primitive but functional task manager. The simplicity is the feature — there's no system to learn, no tool to configure, and no workflow to follow.
Where todo lists are strong
Zero setup cost. Open a text file. Type tasks. You're done. No board configuration, no column naming, no workflow design. A todo.txt file in your project root is a functional project management system that costs nothing and loads instantly.
Tired of bloated PM tools?
GritShip is project management for developers who'd rather ship than configure.
Natural for sequential thinking. When you're debugging a gnarly issue or implementing a feature step-by-step, your brain already thinks in sequences: first do X, then Y, then Z. A todo list mirrors that mental model perfectly. You don't need to decide which "column" a debugging step belongs in.
Works everywhere. A todo list doesn't require a specific tool, an internet connection, or even a screen. You can keep one in a markdown file, a sticky note, a text message to yourself, or the comments section of the file you're editing. This universality means there's zero chance of being locked out of your task list because a SaaS product is down.
Infinite flexibility. A todo list can hold anything — code tasks, grocery items, call reminders, and architectural decisions — in the same file. There's no schema to violate. Add a line, indent for sub-items, use whatever notation makes sense to you.
0
Setup time
open a file, start typing
∞
Flexibility
no schema, no rules
1
Concept to learn
write it down, cross it off
Where todo lists break down
No state visibility. A todo list has two states: done and not done. There's no "in progress," no "blocked," no "in review." When you're juggling three features across different stages, a flat list can't show you what's actually happening right now versus what's queued up for later.
Infinite growth. Todo lists have no natural constraint. Every idea, bug report, and "I should probably..." gets appended. Within weeks, you're staring at 60 items and the list itself becomes a source of stress rather than clarity. The cognitive load of scanning an ever-growing list erodes the simplicity that made it useful in the first place.
There's a psychological dimension to this too. A long todo list creates a persistent sense of being behind. Every unchecked item is a small reminder of something you haven't done. Kanban boards avoid this because "To Do" is just one column — your eye can focus on "In Progress" without being pulled toward the full backlog.
No flow visualization. You can't see bottlenecks. If 15 tasks are piling up in an unacknowledged "waiting for code review" state, a todo list won't show you that. You'd need to mentally reconstruct the state of every item, which defeats the purpose of writing things down.
Priority rot. Items at the bottom of a long todo list effectively cease to exist. You stop scrolling past item 20, so tasks 21 through 60 are invisible. Unlike a kanban board where you can see the full scope of a column at a glance, a todo list buries older items under newer ones. Important-but-not-urgent work sinks and stays sunk.
What a kanban board actually is
A kanban board is a visual system where tasks move through columns representing workflow states. The classic developer setup is three columns: To Do → In Progress → Done. Each task is a card that physically moves from left to right as work progresses.
The word "kanban" literally means "visual signal" in Japanese — and that's the core value proposition. Instead of holding the state of your work in your head (or in a flat list), you externalize it into a spatial layout where position carries meaning. A card's column tells you its state without reading a single word.
The key insight of kanban isn't the board — it's the constraints. Kanban was designed at Toyota in the 1940s to limit work-in-progress. The board is just the visualization layer for a deeper principle: stop starting, start finishing.
For developers, the translation is direct. Your "factory floor" is your codebase. Your "inventory" is your pile of half-finished features, open PRs, and unmerged branches. Kanban makes that pile visible and gives you a mechanism — WIP limits — to keep it from growing out of control.
Where kanban boards are strong
State at a glance. One look at a kanban board and you know exactly what's in progress, what's waiting, and what's done. You don't need to mentally parse a list — the spatial layout does the thinking for you. This becomes critical when your project has tasks in multiple stages simultaneously.
WIP limits enforce focus. The most powerful feature of kanban is one most developers ignore: work-in-progress limits. Setting a limit of 2 cards in your "In Progress" column means you physically can't start a third task until you finish or move one. This is an external constraint against the developer's worst habit — starting new things instead of finishing current ones.
Without WIP limits, it's easy to have eight things "in progress" and make 5% progress on each per day. With a limit of 2, you're forced to complete one thing before pulling in the next. The result isn't just better focus — it's faster throughput. Counterintuitively, limiting your active work makes you ship more, not less.
Flow tracking. When tasks move across columns, you can see where work gets stuck. If your "Code Review" column always has 5 cards while "In Progress" has 1, that's a visible bottleneck. Todo lists hide this information entirely.
Completion momentum. There's a psychological difference between checking off a list item and dragging a card into "Done." The spatial movement — watching a card physically travel from left to right — creates a stronger sense of progress. Over a week, seeing the "Done" column fill up provides tangible evidence that you're shipping, not spinning.
3
Columns minimum
To Do / Doing / Done
2
Ideal WIP limit
for solo developers
< 5 min
Setup time
for a basic board
Where kanban boards break down
Setup overhead. Even a simple kanban board requires decisions: How many columns? What are the states? Do I need swimlanes? These decisions feel trivial but create friction before you've managed a single task. For work you'll finish in one sitting, setting up a board is genuinely overkill.
Can feel like ceremony. Moving a card from "To Do" to "In Progress" to "Done" for a 10-minute bug fix adds zero value. You already know you're doing it, and you'll know when it's done. The ceremony of dragging cards can feel like productivity theater when the work itself is simple.
Premature structure. Not all work has a predictable flow. Early-stage exploration — spiking on a new API, prototyping a UI concept, investigating a performance issue — doesn't move cleanly through states. Forcing exploratory work into a kanban workflow creates friction without adding clarity.
Board maintenance. Kanban boards require occasional grooming. Cards accumulate in "Done" and need archiving. Stale cards in "To Do" need pruning. Labels and priorities drift out of sync. This maintenance is lightweight — maybe 10 minutes a week — but it's a cost that todo lists don't have. A todo list maintains itself because you either cross things off or you don't.
The 5 dimensions that actually matter
Most kanban-vs-todo comparisons devolve into feature checklists. That's useless. What matters is how each approach performs on the dimensions that affect your daily work as a developer. Not "which has more features" — but which gives you better information with less effort.
Here's where each approach genuinely earns its keep and where it doesn't.
1. Visibility
Kanban wins decisively.
A kanban board answers "what's the state of my work?" in a single glance. You see what's queued, what's active, and what's done without reading a single word — the spatial position of each card carries the information.
A todo list requires you to scan every item and mentally reconstruct state. Is this task started? Is it blocked? You'd need annotations, tags, or symbols to encode what kanban shows structurally. And the moment you add those annotations, you're building a worse kanban board inside a text file.
For a developer with 10 active tasks across a project, the visibility difference is stark. A kanban board shows you: 3 things queued, 2 in progress, 2 in code review, 1 blocked, 2 done this week. A todo list shows you: 8 unchecked boxes and 2 checked boxes. Same tasks, radically different information density.
2. Setup time
Todo list wins decisively.
Opening a file and typing - [ ] Fix auth redirect bug takes three seconds. Setting up a kanban board — even a minimal one — takes minutes of column naming and workflow decisions. For developers who switch between projects frequently, the per-project setup cost of kanban boards adds up. If you touch five projects in a week, that's five boards to create and maintain versus one text file with five headings.
This gap narrows with tools that provide sensible defaults. A board that launches with "To Do / In Progress / Done" pre-configured eliminates the decision overhead — you just add cards. But a todo list still wins on raw speed because there are genuinely zero decisions to make. There is no faster task management setup than opening a file and typing.
3. Context switching
Kanban wins — if you use WIP limits.
A kanban board with WIP limits is the only system in this comparison that structurally prevents you from juggling too many things at once. A todo list has no mechanism for this. You can write "FOCUS: only work on 2 things" at the top, but there's nothing stopping you from ignoring it.
The caveat: most developers set up kanban boards without WIP limits, which removes kanban's strongest advantage. A kanban board without WIP limits is just a spatially arranged todo list. If you're going to use kanban, set WIP limits. A limit of 2 in "In Progress" is the recommendation for solo developers. For a 2–3 person team, 3–4 is reasonable. The number matters less than having one at all.
4. Collaboration
Kanban wins for teams.
When two or more people work on the same project, shared state becomes essential. A kanban board makes everyone's current work visible — you can see what your teammate is working on without asking. This eliminates "are you still working on that?" conversations and prevents two people from accidentally picking up the same task.
Todo lists can be shared, but they don't communicate state. A shared Google Doc with checkboxes doesn't tell you who's working on what right now. You'd need to add assignee tags, status markers, and timestamps — at which point you've reinvented a kanban board with worse UX.
Even a two-person team benefits significantly. If your co-founder picks up a task while you're sleeping (common in distributed teams), a kanban board shows that change the moment you open it. A shared todo list requires you to scan through items and notice which ones your co-founder checked off — assuming they remembered to check them off at all.
For solo developers, this dimension is irrelevant. If you're the only person, there's no state to share.
5. Simplicity
Todo list wins for conceptual simplicity.
A todo list has one concept: the item. A kanban board has at minimum three: the card, the column, and the flow between them. Add WIP limits, swimlanes, priorities, and labels, and the concept count grows quickly.
This matters more than developers typically admit. Every concept in your PM system is cognitive overhead that competes with the actual problem you're solving. A todo list imposes almost zero cognitive tax. A kanban board imposes some — and the question is whether that tax pays for itself in visibility and flow control.
The simplicity advantage is most pronounced for developers who work across many small projects. If you maintain six open-source packages and three client projects, creating and maintaining a kanban board for each is nine boards to keep current. Nine todo lists — or even one big one with headers — is practically zero maintenance by comparison.
When todo lists beat kanban
Todo lists aren't the inferior option. They're the right option in specific, common situations.
Single-threaded personal work. If you're the only person working and you do one thing at a time until it's done, a todo list is all you need. The sequential model matches your workflow perfectly. Adding columns and cards creates overhead with no payoff. You're essentially a single-threaded process — there's no concurrency to visualize.
Daily checklists. Morning routines, deployment checklists, code review steps — anything you'll complete in a single session. These are linear by nature. A checklist in markdown (- [ ] / - [x]) is the ideal format. Putting "make coffee" and "run database migrations" on a kanban board is a parody of process. The overhead of creating cards, assigning columns, and dragging them across doesn't pay for itself when the entire list will be finished in 90 minutes.
Quick capture. When ideas, bugs, and tasks arrive faster than you can process them, a todo list is the fastest capture mechanism. You don't need to decide which column something belongs in — just write it down. You can triage later (or never, if it turns out not to matter). A developer halfway through a debugging session who notices three unrelated issues needs to dump them somewhere fast — a todo list handles this in seconds. No context switch to a board. No decisions about priority or state. Just write and get back to work.
Ephemeral work. Tasks you'll finish today and never think about again don't need the ceremony of a kanban board. If your todo list resets to empty every evening, the simplicity is a feature. Kanban boards accumulate completed cards that need archiving — another small maintenance cost that todo lists simply don't have.
Concrete example. You're fixing a production bug. Your todo list for the next two hours looks like this:
Reproduce the issue locally
Check auth middleware logs
Write a failing test for the edge case
Fix the conditional in handleRedirect
Verify fix passes in staging
Deploy to production
Every item will be done in one sitting. None of them need a "state." Creating six kanban cards for this and dragging each through three columns would triple your interaction time without adding any information you don't already have.
💡 The litmus test for todo lists
If every item on your list will be finished in one sitting, you don't need state tracking. A todo list is the right tool. The moment tasks start spanning multiple days or requiring handoffs, you've outgrown it.
When kanban beats todo lists
Kanban isn't universally better, but it's specifically better when your work has certain characteristics.
Multi-day work across states. When tasks take days or weeks and move through distinct phases — planning, implementation, code review, deployment — a kanban board tracks that progression naturally. A todo list forces you to annotate state manually ("🔨 implementing auth flow" or "⏳ waiting on API response"), which is fragile and inconsistent. One forgotten emoji and you've lost track of where something stands.
Collaborative projects. The moment a second person touches your project, shared state visibility becomes non-negotiable. A kanban board makes it structurally impossible to miss that your co-founder is blocked on the payments integration while you're building a feature that depends on it. Todo lists hide this information. The communication overhead of "hey, where are you on X?" conversations disappears when the board answers that question before it's asked.
Work with review or approval steps. If your tasks have a "needs review" state — pull request reviews, design feedback, client approval — kanban makes that queue visible. Without a kanban board, "waiting for review" tasks disappear into the middle of a todo list, and you forget to follow up for days. A visible "In Review" column with two cards sitting there for 48 hours is an immediate signal that your review process is a bottleneck — something a todo list will never tell you.
Open-source maintainers managing contributions. If you maintain a project that accepts pull requests, a kanban board with columns like "Triage → In Review → Needs Changes → Approved → Merged" gives you a clear picture of your contribution pipeline. A todo list of "review PR #42, review PR #51, review PR #67" doesn't tell you which PRs you've already started reviewing versus which are fresh. Pair this with the P1–P4 prioritization framework to decide which PRs get reviewed first, not just how they flow.
Anything with WIP that needs limiting. If you routinely find yourself with 5 things "in progress" and none of them finishing, a kanban board with WIP limits is the structural intervention you need. It's the difference between knowing you shouldn't multitask (which everyone knows) and having a system that prevents it (which almost no one has).
Concrete example. You're building a feature that touches frontend, backend, and database. Your kanban board shows:
To Do: Add API rate limiting, Write migration for user_preferences table
In Progress: Build settings UI component, Implement /api/settings endpoint
In Review: Refactor auth middleware (PR #147, waiting on co-founder)
Blocked: Deploy billing integration (waiting on Stripe webhook verification)
One glance tells you everything: you're actively working on two things (good, that's your WIP limit), one thing needs your co-founder's review, and one thing is blocked on an external dependency. A todo list would show these as four unchecked items with no distinction between "actively coding" and "waiting on Stripe for three days."
ℹ️ The litmus test for kanban
If you've ever asked yourself "wait, what was I working on?" or "is this task still in progress or did I finish it?", you need state visibility. That's what kanban provides. If those questions never arise, stick with your todo list.
The hybrid approach most developers actually use
Here's what nobody tells you in comparison articles: the best system for most developers isn't kanban or a todo list. It's both.
The pattern that works looks like this: kanban for project work, todo list for daily tasks. The kanban board answers "what am I building this week?" The todo list answers "what am I doing right now?" They operate at different zoom levels, and trying to make one tool do both jobs is why developers keep abandoning their systems.
In practice, this means your kanban board has 5–10 cards representing features, bugs, and improvements that move through your workflow over days. Your daily todo list has 3–5 items representing the concrete steps you'll take today to advance those cards.
The kanban card might say "Implement user authentication." Today's todo list says:
Set up Supabase auth helpers
Build login form component
Write auth middleware for protected routes
Test OAuth redirect flow
When all four items are checked off, the kanban card moves from "In Progress" to "Review." Tomorrow, a new set of daily tasks appears for whatever card you're working on next.
This separation solves a real problem: kanban cards that are too granular and todo lists that are too abstract. The kanban card "Implement user authentication" is the right level of abstraction for project tracking — you can see it's in progress and estimate when it'll be done. But it's useless as an instruction for what to do next. Your daily todo list fills that gap with specific, actionable steps.
💡 The hybrid setup
Weekly scope: A kanban board with 3 columns (To Do / In Progress / Done) and a WIP limit of 2 in the "In Progress" column. This is your project-level view.
Daily scope: A simple checklist — in a markdown file, a notes app, or even on paper — with the 3–5 tasks you'll finish today. This is your execution-level view.
The link: Every daily task maps to a kanban card. When you finish all daily tasks for a card, you move the card forward. The kanban board tracks progress; the todo list tracks action.
This hybrid approach gives you the strategic visibility of kanban (what's the state of my project?) without losing the tactical simplicity of a todo list (what do I do next?). Most developers who report successful project management systems — across Hacker News, Reddit, and Indie Hackers forums — describe some variation of this pattern whether they name it or not.
The hybrid approach also solves the granularity problem. Kanban cards should represent meaningful chunks of work — "Implement user authentication" or "Redesign dashboard layout." They shouldn't represent individual steps like "add email validation regex." Those atomic steps belong in your daily todo list, where their short lifespan matches the simplicity of the format. Mixing granularity levels on a kanban board is how you end up with 40 cards in "To Do" and a board that feels as overwhelming as the todo list you were trying to escape.
One last advantage of the hybrid: it gives you a natural daily kickoff ritual. Each morning, look at your kanban board (30 seconds), pick the card you're advancing today, and write your 3–5 daily tasks for it. That ritual takes under two minutes and replaces any need for daily standups, complex planning sessions, or elaborate priority frameworks. For a fuller daily + weekly cadence built on this hybrid model, see our solo developer's guide to PM without bloat.
The developer's decision tree
If you're still unsure, work through this:
Are you working alone on a single project?
If yes: start with a todo list. You can always add a kanban board later if you outgrow it. Don't add structure you don't need yet. The cost of switching from a todo list to a kanban board later is near zero — you just move your unchecked items into cards. The cost of maintaining a kanban board you don't need is ongoing.
Are you working on multiple things with different states?
If yes: use a kanban board. The moment you have tasks in "waiting for review," "blocked," and "in progress" simultaneously, you need state columns. A todo list will lose track. You'll find yourself re-reading the entire list multiple times a day to reconstruct what's happening, which is the exact problem a kanban board solves.
Are you collaborating with others?
If yes: use a kanban board. Shared state visibility isn't optional when more than one person is contributing. Tools like GritShip make this trivially fast — a 3-column board with real-time updates takes under two minutes to set up, so the "overhead" argument disappears.
Do you need to track what's blocked vs. in progress?
If yes: kanban. This is the single clearest signal. If your work has "blocked" as a meaningful state, you need columns to represent it. Todo lists have no concept of "blocked" — a blocked item looks identical to one you haven't started.
Is your work mostly short, same-day tasks?
If yes: todo list. Kanban adds nothing for tasks that are created, executed, and completed within hours. Use a checklist, enjoy the dopamine of checking things off, and save the board for work that actually spans time.
Are you building something with multiple moving parts?
If yes: kanban. When you're shipping a feature that involves frontend components, API endpoints, database migrations, and deployment configuration, a kanban board shows you which parts are done and which are still open. A todo list would flatten this into an undifferentiated sequence where it's impossible to see overall progress.
ℹ️ The honest answer
Most developers doing real project work — shipping features, fixing bugs across multiple systems, collaborating with even one other person — benefit from a kanban board. Todo lists are better for daily execution within that larger structure. The two aren't competing; they operate at different zoom levels.
What most developers get wrong
The biggest mistake isn't choosing the wrong system. It's over-configuring the right one.
Developers who adopt kanban tend to create too many columns. You don't need "Backlog → Triage → Refined → Sprint Ready → In Progress → Code Review → QA → Staging → Done." You need three columns. Maybe four. Start with the minimum and add a column only when you repeatedly feel the absence of a specific state. Every column you add is a new decision point for every task — "does this go in Code Review or QA?" — and those micro-decisions accumulate into real friction. This is a miniature version of feature bloat killing developer productivity — complexity you add to your own system has the same cost as complexity the tool adds.
Developers who stick with todo lists tend to let them grow without bounds. A 50-item todo list isn't a productivity tool — it's an anxiety artifact. If your list has more than 10–15 items, you're not prioritizing. You're collecting. Set a hard cap: when the list hits 15, you must delete or defer 5 items before adding anything new.
The third common mistake is confusing the tool with the system. Switching from Todoist to Things to Apple Reminders doesn't change your todo list system — it just burns transition time. Migrating from Trello to Notion to Linear doesn't change your kanban system — it just rearranges the furniture. The system is the structure (list vs. board vs. hybrid), the constraints (WIP limits, list caps), and the habits (daily review, weekly cleanup). The tool is just the container.
Both systems fail when you spend more time maintaining them than using them. If you're spending 30 minutes a day grooming your kanban board or reorganizing your todo list, the system is costing more than it's worth. The right system for a developer takes less than 5 minutes of daily overhead. If it takes more, simplify.
There's a subtler mistake too: switching systems every few weeks. Every new tool or approach has a learning curve that costs you 2–3 days of reduced productivity. If you switch four times a year, you've burned over a week just on transitions. Pick one approach (or the hybrid), commit to it for at least a month, and only change if there's a specific, identifiable problem — not just the vague feeling that something better exists.
Finally, beware the "productivity as procrastination" trap. Spending an hour customizing your kanban board's labels and colors, or writing a Python script to parse your todo.txt file into a dashboard, feels productive because you're working on your workflow. But optimizing the system that tracks your work is not the same as doing the work. The developers who ship consistently have boring, stable systems they rarely think about. The ones who tweet about their setups are often polishing the system instead of using it.
How to transition between the two
If you've been using a todo list and you're ready to try kanban, start small. Take your current list and sort it into three columns. Don't try to import your entire backlog. Pick the 5–10 most relevant tasks, drop them into "To Do," and start working. The remaining items stay in a separate "someday" list that you review weekly.
If you've been using a kanban board and you're finding it heavy for your current work, don't feel guilty about switching back to a todo list. It's not a regression — it's right-sizing your system. Export your in-progress cards as a simple checklist, archive the board, and move on. You can always spin up a new board when the work justifies it.
The transition itself should take less than 10 minutes. If it takes longer, you're over-thinking it. The goal is to track your work, not to perfectly migrate your data. Start fresh, carry only what's active, and let the old system become a read-only archive.
💡 Transition rule of thumb
If your current system makes you feel organized but you're not shipping, the system is the problem. If your current system feels scrappy but you're consistently shipping, leave it alone. The measure of a productivity system is output, not aesthetics.
The bottom line
Todo lists and kanban boards solve different problems at different scales. A todo list manages what needs doing. A kanban board manages how work flows. When your work is simple and sequential, a list is enough. When your work has multiple states, involves other people, or spans days, a board earns its keep. Neither is obsolete. Neither is universally superior.
The best approach for most developers isn't a binary choice. Use a kanban board for project-level tracking — your features, bugs, and improvements moving through states. Use a todo list for daily execution — the concrete steps you'll take today. The board gives you visibility. The list gives you focus. Together, they cover what neither does alone.
If you're looking for a kanban tool that doesn't require a 30-minute setup or a $10/month subscription, GritShip gives you a 3-column board with keyboard shortcuts and sub-200ms interactions — the developer-friendly defaults without the enterprise baggage. But the tool matters far less than the habit.
Don't over-think this. Pick the approach that matches your current work, use it for two weeks, and adjust. The developers who ship the most aren't the ones with the best PM system. They're the ones who spent five minutes choosing a system and five months actually using it.
Frequently asked questions
Is a kanban board better than a todo list?
Neither is universally better — they solve different problems. Kanban boards are better for multi-day work with distinct states (in progress, in review, done), collaborative projects, and work that needs WIP limits to prevent multitasking. Todo lists are better for single-session tasks, daily checklists, and sequential personal work. Most developers benefit from using both: a kanban board for project-level tracking and a todo list for daily execution.
When should a developer use a kanban board?
Use a kanban board when your work has multiple meaningful states beyond 'done' and 'not done' — for example, tasks that move through implementation, code review, and deployment. Kanban is also the right choice when collaborating with others (shared state visibility becomes essential), when you need to limit work-in-progress to maintain focus, or when tasks regularly span multiple days.
Can you use both kanban and a todo list together?
Yes, and many productive developers do exactly this. The common pattern is using a kanban board for weekly project scope (features and bugs moving through workflow states) and a daily todo list for concrete execution steps. Each daily task maps to a kanban card. When all daily tasks for a card are done, the card moves forward on the board. The board tracks progress; the list tracks immediate action.
What's the simplest kanban setup for developers?
Three columns — To Do, In Progress, and Done — with a WIP limit of 2 cards in the 'In Progress' column. That's the entire setup. You can create this in any kanban tool in under two minutes. Don't add more columns until you repeatedly feel the absence of a specific state like 'Blocked' or 'In Review.' Most solo developers never need more than 3–4 columns.
Do kanban boards work for solo developers?
Yes, especially when your solo work spans multiple days and has distinct phases. A solo developer building features that go through implementation, testing, and deployment benefits from seeing that flow visually. The key advantage for solo devs is WIP limits — they structurally prevent the common habit of starting five things and finishing none. For very simple, single-session work, a todo list is sufficient.
How many columns should a developer's kanban board have?
Start with 3 columns: To Do, In Progress, and Done. Add a fourth column only when you consistently have tasks in a state that doesn't fit the existing three — common additions are 'Blocked' or 'In Review.' Most solo developers never need more than 4 columns. Teams with code review workflows often use 4–5: To Do, In Progress, In Review, QA, and Done. More than 5 columns usually means you're over-engineering your process.
What are the disadvantages of kanban for developers?
Kanban has three main drawbacks for developers. First, setup overhead: even a simple board requires column decisions before you manage your first task. Second, ceremony for small tasks: dragging a card across three columns for a 10-minute bug fix adds no value. Third, premature structure: early-stage exploration and prototyping doesn't flow through predictable states, so kanban can add friction to creative or investigative work. For short, single-session tasks, a todo list is simpler and faster.