Task Management Methods: Kanban, Agile, GTD and When to Use Each

Task management methods are the rules a person or team uses to decide what gets worked on, in what order, and how progress is made visible. Kanban, Scrum, Getting Things Done, the Eisenhower matrix and time-blocking are all task management methods. Trello, Jira, Asana and Notion are not — they are containers. A method decides how work flows through the container, and most teams that complain their tool "isn't working" have picked a tool without ever picking a method.

That distinction is the reason this guide exists. Teams of 10 to 500 people rarely fail at task management because they lack software. They fail because three people run the same board three different ways, because a backlog of 400 items has quietly become a graveyard, or because the work that recurs every week is being re-typed as a fresh task every Monday. Each of those is a method problem and no amount of switching apps fixes it.

This guide is written for the operations, IT, HR and team leads who have to make a method stick across a group of people with different habits. It covers the three major methods in enough depth to run them properly, four lighter techniques worth borrowing from, a comparison table, a decision guide for choosing between them, a six-step rollout plan, and the mistakes that usually undo the whole effort. By the end you should be able to name the method your team is using, say why, and explain which parts of your work do not belong in a task list at all.

Why the Method Matters More Than the App

Every task management tool ships with defaults: a list, a board, a due date field, an assignee field. The defaults are deliberately neutral so that any team can start using the tool in five minutes. That neutrality is also the trap. A tool with no method attached becomes a shared inbox that everyone dumps into and nobody empties.

The symptoms are familiar. Due dates are set optimistically and then ignored, so they stop meaning anything. Most items are marked "high" priority, so "high" stops meaning anything. The In Progress column holds 40 cards for a team of six, which means nothing is actually in progress — it is all in waiting. And the person who set the tool up is now the only one who understands the labels.

A method fixes this by answering questions the tool leaves open. How many things can one person work on at once? What has to be true before a task is allowed onto the board? Who decides order — the requester, the assignee, or a single backlog owner? When does the team stop and look at what it has finished? How do we tell a genuine one-off task from the twentieth run of a monthly process? Kanban, Scrum and GTD each give different answers, and the answers are what make a tool useful.

Tasks versus processes

Before comparing methods, it is worth separating two kinds of work that get lumped together on the same board. A task is a discrete piece of work with a definable end: write the Q3 board pack, fix the printer on the second floor, reply to the tender. It happens once. A process is a sequence of steps that repeats: onboarding every new starter, closing the books every month, patching servers every second Tuesday, publishing the social calendar every day. It happens again and again, the same way, and the value comes from consistency.

Task management methods are designed for tasks. When a process is forced into a task list, one of two things happens. Either someone re-creates the twelve steps of the process as twelve fresh tasks every time it runs — which is tedious, so they soon stop and write "do onboarding" as one task instead — or the steps are never written down at all and the process lives in one person's head. Neither gives the team a record of what was actually done. The right home for a repeating process is a workflow or a checklist that can be run as many times as needed, with each run tracked separately. We return to this split throughout the guide, because it is the single most useful thing an operations lead can learn about task management.

Kanban: Columns, WIP Limits and Flow

Kanban started as a physical signalling system on the Toyota production line, where a card (the Japanese word kanban) travelling upstream told the previous station to produce more parts. The idea was pull rather than push: nothing is made until something downstream asks for it. David Anderson adapted the principle for software and knowledge work in the late 2000s, and the version most teams use today comes from that adaptation.

The visible part of Kanban is a board with columns representing stages of work — To Do, In Progress and Done at a minimum, with columns such as Awaiting Review or Blocked added as the team learns where work gets stuck. Cards move left to right, and anyone looking at the board can see what is being worked on, by whom, and where the queue is building. That visibility is only the first of Kanban's three mechanisms.

Work-in-progress limits

The second and most important mechanism is the WIP limit: a cap on the number of cards allowed in a column at any time. An In Progress column limited to four cards for a team of four means nobody is allowed to start a new card until one finishes. This feels restrictive for the first fortnight and then becomes the thing the team refuses to give up, because it forces two behaviours that never happen otherwise: people finish things before starting new ones, and blocked work gets unblocked quickly because it is visibly occupying a slot that someone else needs.

Setting the limit is a matter of experiment. A common starting point is one card per person in the column plus one, then tightening until the team feels the constraint. If the limit is never hit, it is too generous to change behaviour. If it is hit every hour, the column probably needs splitting into two stages so that the real bottleneck is exposed.

Flow metrics

The third mechanism is measurement. Because every card has a timestamp when it enters and leaves each column, Kanban gives a team four numbers that a to-do list never can:

• Lead time — how long a card takes from being requested to being done. This is what the customer or internal requester experiences.
• Cycle time — how long a card takes from being started to being done. This is what the team controls.
• Throughput — how many cards finish per week or per month.
• Work in progress — how many cards are started but unfinished at any moment.

These are connected by Little's Law, a queuing theory result that says average WIP equals average throughput multiplied by average lead time. In plain terms: if the team's throughput is fixed by its size, then the only way to shorten lead time is to reduce WIP. This is why the WIP limit is not a management preference but arithmetic. An IT support team that lets 60 tickets sit open with five engineers will have long lead times no matter how hard those engineers work; capping open tickets and finishing them in order will shorten the queue for everyone.

Where Kanban fits

Kanban suits work that arrives continuously and unpredictably: support desks, facilities, marketing requests, legal reviews, any team that serves internal customers. It imposes no rhythm, so it is easy to adopt and easy to combine with other methods. That is also its weakness — with no fixed cadence, a team can drift without ever asking whether the right things are on the board, so schedule a fortnightly review of the metrics and the blocked column anyway.

Agile and Scrum: Backlogs, Sprints and Ceremonies

Agile is not a task management method. It is a set of values, written down in the 2001 Agile Manifesto by a group of software practitioners, that favours working increments over documents, collaboration over contracts, and responding to change over following a plan. Scrum is the most widely used framework that turns those values into a repeatable way of managing work, and when people say "we run Agile" they nearly always mean Scrum or something derived from it.

Scrum was formalised by Ken Schwaber and Jeff Sutherland and is defined in the Scrum Guide, a short document they still maintain. It was written for software teams, but its structure — a prioritised backlog, fixed-length iterations and a small number of mandatory meetings — has been adopted by marketing, HR, internal IT and operations groups with reasonable success.

The backlog

Everything the team might do lives in a single ordered list called the product backlog, and one person, the Product Owner, is responsible for its order. This is the part non-software teams most often skip and most often regret skipping. Without a single owner, the backlog becomes a wish list where every stakeholder's request sits at "top priority" and order is decided by whoever shouted most recently. With one, the team has one place to send requests and one person accountable for saying "not this sprint".

Sprints

Work is done in sprints: fixed periods, usually two weeks and never more than four, at the end of which the team delivers something finished. At the start of each sprint the team pulls items from the top of the backlog, committing only to what it believes it can complete, and nothing new is added mid-sprint except by agreement. The point of the fixed length is predictability, not speed. After three or four sprints a team knows roughly how much it can finish in a fortnight, and planning becomes arithmetic rather than hope.

The ceremonies

Scrum prescribes four events per sprint, and the discipline of actually holding them is what separates teams that get value from Scrum from teams that just have a board with a Sprint column:

• Sprint planning — the team selects what to commit to and agrees how it will be done. A structured sprint planning checklist keeps this to an hour or two rather than a half-day argument.
• Daily scrum — a 15-minute stand-up where each person says what they finished, what they will do next, and what is blocking them. It is a coordination meeting, not a status report to the manager.
• Sprint review — the team shows what it finished to stakeholders and gets feedback that reshapes the backlog.
• Sprint retrospective — the team looks at how it worked, not what it worked on, and picks one or two things to change next sprint.

The roles

Scrum names three roles. The Product Owner orders the backlog and is the single voice of what matters most. The Scrum Master owns the process — runs the ceremonies, removes impediments, protects the team from mid-sprint interruptions — and is explicitly not the team's manager. The Developers (the Scrum Guide's term; read it as "the people doing the work") self-organise to deliver the sprint commitment. Collapsing the first two roles into one person, or making the line manager the Scrum Master, are the two most common ways a Scrum adoption quietly turns back into command and control.

Where Scrum fits

Scrum suits project work with a defined goal that can be delivered in increments: a product build, a website migration, an office move, an ERP implementation, a quarterly campaign. It is a poor fit for interrupt-driven work, because the sprint commitment breaks every time an urgent ticket lands, and for repeating operational processes, because a monthly close does not benefit from being replanned into a sprint every time it happens.

Getting Things Done: Capture, Clarify, Organise, Reflect, Engage

Getting Things Done is a personal task management method described by David Allen in his 2001 book of the same name. Unlike Kanban and Scrum, GTD is not about a team's shared work; it is about how one person keeps every commitment they have made out of their head and in a trusted system, so that the head is free to think. Allen's core observation is that an unrecorded commitment keeps nagging at you whether or not you are in a position to act on it. Write it down somewhere you will definitely look, and the nagging stops.

GTD has five stages, and the method works only when all five are practised. Most people who "tried GTD and it didn't stick" did the first two and skipped the fourth.

Capture

Everything that has your attention — an email that needs a reply, a thought in the shower, a request from a colleague in the corridor — goes into an inbox the moment it occurs. Not a mental note. An inbox: a notes app, a paper pad, an email to yourself, a voice memo. The rule is that there are as few inboxes as possible and that they are all emptied regularly.

Clarify

Each captured item is processed with two questions. Is it actionable? If not, it is binned, filed as reference, or parked on a Someday/Maybe list. If it is actionable, what is the very next physical action? "Sort out the supplier contract" is not an action; "email Priya asking for the current contract PDF" is. Anything that will take less than two minutes is done immediately rather than recorded — Allen's two-minute rule — because recording it would take longer than doing it.

Organise

Clarified actions are sorted into lists by context (calls to make, things to do at the office, things to raise with a specific person) and multi-step outcomes are recorded as projects with their next action identified. Anything date-specific goes on the calendar and nowhere else. Anything waiting on someone else goes on a Waiting For list with the date it was delegated, which is the GTD feature most useful to managers.

Reflect

The weekly review is the stage that makes GTD hold together. Once a week, the practitioner empties every inbox, reviews every project to confirm it has a next action, checks the Waiting For list for things to chase, and looks at the calendar for the fortnight ahead. It takes an hour. Skip it for three weeks and the system is no longer trusted, at which point the head starts holding commitments again and the method has failed.

Engage

With everything captured and organised, choosing what to do in a given moment becomes a matter of context, time available, energy available and priority — in that order. GTD deliberately puts priority last: the highest-priority item is irrelevant if you are on a train without a laptop and it needs a spreadsheet.

Where GTD fits

GTD is the strongest of the three methods for an individual with a high volume of small, varied commitments: a manager, an account handler, an IT lead fielding requests from every department. It is weak as a team method because it has no shared view and says nothing about capacity — a GTD practitioner can have a perfectly organised system containing three times more work than they can do. Pairing it with a team-level Kanban board, so that shared work is visible and capped, addresses both gaps.

Four More Techniques Worth Borrowing

The three big methods are complete systems. The following techniques are narrower, but each solves a specific problem well and each can be dropped into any of the three without conflict.

The Eisenhower matrix

Popularised by Stephen Covey and named after a remark attributed to Dwight Eisenhower, the matrix sorts tasks on two axes — urgent or not, important or not — into four quadrants. Urgent and important gets done now. Important but not urgent gets scheduled; this is the quadrant the matrix exists to protect, because planning, process improvement and training live there and it is what disappears when a team is constantly firefighting. Urgent but not important gets delegated. Neither gets dropped. The matrix is a triage tool, not a system; use it when a backlog has become unmanageable and you need a fast, defensible way to cut it.

Time-blocking

Time-blocking moves tasks from a list onto the calendar as appointments with yourself. Its advantage over a list is that it confronts capacity honestly: a list can hold 30 items, but a Tuesday can hold about six hours of focused work, and blocking makes the gap visible before the week starts rather than at the end of it. It pairs naturally with GTD and with Scrum. Its weakness is fragility — one urgent interruption knocks every subsequent block along, so blocks need slack around them.

Pomodoro

Francesco Cirillo's technique from the late 1980s: work for 25 minutes on one task with no interruptions, take a five-minute break, repeat, and take a longer break after four rounds. It is a focus technique rather than a planning one, and it works because it makes starting cheap — anyone can commit to 25 minutes. It is unsuited to work that needs long uninterrupted stretches, and it should never be imposed on a team by a manager; it is a personal tool.

Checklists as a method

A checklist is the oldest task management technique of all, and it is the right method for a class of work that the other methods handle badly: the repeating process. Atul Gawande's account of the WHO Surgical Safety Checklist showed that a short, well-designed checklist run by already-expert surgical teams cut deaths and complications substantially across hospitals in eight countries. The checklist did not tell the surgeons anything they did not know. It made sure that what they knew was done every time, under pressure, by whoever was in the room.

That is exactly the property an operations team needs for onboarding, close, patching, audits and handovers — and exactly the property a task list cannot provide, because a task list has no memory of how the work was done last time. A checklist that is designed well, assigned to named people and run on a schedule is a task management method in its own right. The guide to creating checklists that actually get used covers the design side; the rest of this article covers how to combine checklists with the flow methods above.

Task Management Methods Compared

The table below puts the methods side by side on the questions that matter when choosing one for a team. "Tooling" describes what the method needs at minimum, not what vendors will sell you.

How to Choose a Task Management Method

Most teams choose a method because someone on the team used it at a previous employer. That is not a bad reason, but it is a weak one when the previous employer was a 40-person software company and the current team is an HR department of six. The better route is to characterise the work first and let the method follow. Four questions do most of the work.

Does the work arrive continuously or in projects?

If requests turn up every day from people outside the team and each one is different, that is flow work and Kanban is the natural fit. If the team is delivering something with a defined end state over weeks or months, that is project work and Scrum's sprint rhythm gives stakeholders the checkpoints they want. Many teams have both — an IT team with a helpdesk and a migration project — and should run them separately rather than forcing one method over both.

How much of it repeats?

Walk through last month's completed work and mark each item as one-off or repeating. Operations, HR, finance and IT teams are routinely surprised to find that half or more of what they did was the same process running again. That half belongs in checklists, not in the task method, and moving it out is usually the biggest single improvement available. It shrinks the task board to work that actually needs deciding about and gives the repeating work a record that a task board never produces. The guide to process standardisation explains how to identify and document that repeating half.

Who needs to see it?

If the only person who needs to see the work is the person doing it, GTD or time-blocking is enough. If the team needs to coordinate, a shared board is required and the choice is between Kanban and Scrum. If a manager or a client needs to see progress on repeating processes without asking, a checklist platform with a dashboard is required, because boards show cards, not completed steps.

How much ceremony will the team tolerate?

Scrum demands four meetings per sprint and a named backlog owner, and works badly when those are skipped. Kanban asks only for a board and a WIP limit. A team new to any method should usually start with Kanban, build the habit of finishing before starting, and add cadence later if project work needs it. Starting with full Scrum in a team that has never had a shared board tends to produce ceremonies without the behaviour they are meant to create.

A quick decision guide

• Support desk, facilities, marketing requests, legal review, anything interrupt-driven: Kanban with WIP limits.
• A project with a goal, a deadline and stakeholders who want regular visibility: Scrum, with a real Product Owner.
• One busy person juggling many small commitments: GTD, with the weekly review protected in the calendar.
• Repeating operational processes — onboarding, close, patching, audits, daily opening and closing: checklists, run on a schedule and assigned by name.
• A team doing all of the above: Kanban for the flow work, checklists for the repeating work, and a personal method of each person's choosing underneath.

Combining Methods: Kanban for Flow, Checklists for Repeatable Work

The methods are not rivals, and the teams that manage work best almost always run more than one. The combinations below are the ones that recur in well-run operations, IT and HR teams.

Kanban plus checklists

This is the most useful pairing for an operations team. The Kanban board holds the one-off and variable work: incoming requests, improvement tasks, escalations. The repeating processes run as checklists on their own schedule, each run assigned to a named person, with a dashboard that shows which runs are in progress, which are overdue and which steps are stuck. The board is small and honest because it no longer contains 30 copies of "run monthly report", and the checklists produce the audit trail the board never could. A card can link to a checklist run when a request kicks off a standard process, so the two systems reference each other rather than duplicating.

Scrum plus checklists

Scrum's own events are repeating processes, and running them from a checklist is the easiest way to keep them consistent when the Scrum Master is on holiday or the team is new. A sprint planning checklist ensures the backlog was refined, capacity calculated and the sprint goal written down before anyone pulls a card; a sprint review checklist ensures the demo was prepared, stakeholders invited and feedback captured back into the backlog. The Definition of Done most Scrum teams keep is, in effect, a short checklist applied to every item before it moves to Done.

Scrumban

Teams that start with Scrum and find the sprint commitment keeps breaking under interruptions often move to what is loosely called Scrumban: a Kanban board with WIP limits for day-to-day flow, keeping Scrum's fortnightly planning and retrospective without the fixed commitment. It is a sensible destination for internal IT and platform teams, and for any group whose work is roughly half project and half interrupt.

GTD underneath everything

Whatever the team runs, each individual still has to manage their own share of it alongside the emails, corridor requests and personal admin that never reach a shared board. GTD, or a simplified version of it, is the right layer for that. The team method decides what the team works on; the personal method decides what this person does in the next hour. Keeping the two separate stops the shared board filling up with "remember to call the dentist".

Rolling Out a Task Management Method to a Team

Choosing a method takes an afternoon. Getting eight people to use it the same way for six months is the actual work. The following six steps are the ones that separate rollouts that stick from rollouts that become another abandoned board.

Common Task Management Mistakes

The same handful of mistakes account for most failed adoptions. They are worth naming because they look like reasonable decisions at the time.

Personal vs Team Task Management

A great deal of confusion about task management methods comes from applying a personal method to a team, or a team method to a person. They solve different problems and need different tools.

Personal task management is about one person's attention. Its goals are to never forget a commitment, to choose well what to do next, and to protect enough focused time to do it. GTD, time-blocking, Pomodoro and the Eisenhower matrix are all personal methods. The tool can be anything from a notebook to a dedicated app, and it can be private; nobody else needs to read it. The most common mistake is expecting a personal system to also be the team's system, which produces one person with a beautifully organised view of work that nobody else can see.

Team task management is about coordination and capacity. Its goals are that everyone can see what is being worked on, that the team does not start more than it can finish, that priorities are set once rather than argued daily, and that a manager or stakeholder can see progress without interrupting anyone. Kanban and Scrum are team methods. The tool has to be shared, and the discipline has to be collective — a WIP limit that half the team ignores is not a WIP limit.

Process management is a third layer that sits above both, and it is the one most guides to task management leave out. Its goal is that repeating work is done the same way every time, by whoever does it, with a record. Checklists and workflows are its methods, and the tool has to support reuse, assignment and history. A team that has good personal and team task management but no process layer will still onboard people inconsistently and still forget the quarterly review, because those are not tasks. A 90-day onboarding plan, for instance, is forty or fifty steps spread over three months across three or four owners; no card on a board can carry that.

The practical implication for a team lead is to be explicit about which layer a given tool or ritual belongs to. The shared board is the team layer: keep personal reminders off it. The checklist platform is the process layer: keep one-off tasks out of it. Each person's own list is theirs, and the lead's job there is to make sure people have one, not to inspect it.

What to Measure

A method that is not measured cannot be improved, but the wrong measures damage the behaviour they are meant to encourage. The useful metrics differ by layer.

For flow work (Kanban)

Track cycle time, throughput and WIP, and look at the distribution rather than the average — a support team whose median ticket closes in two days but whose slowest 15% take three weeks has a specific, findable problem in that tail. Count how often the WIP limit is hit and how long cards spend in Blocked. Do not track individual throughput as a performance measure; once cards-per-person is a target, people pick small cards and stop swarming on hard ones.

For project work (Scrum)

Track sprint completion rate (planned versus delivered), velocity trend over several sprints, and how much work was added mid-sprint. A team that consistently delivers 60% of what it plans is over-committing, not under-performing, and the fix is at planning. Velocity is useful for the team's own forecasting and harmful as a comparison between teams or as a target.

For repeating processes (checklists)

Track the proportion of runs completed on time, average time to complete a run, which steps are most often late or skipped, and which assignees have overdue steps. These are the metrics a task board cannot give you and the ones an auditor, a client or a director actually asks about: was the onboarding finished before the start date, was the close done by working day five, has every server been patched this cycle. A platform with an analytics and reporting view across all runs turns those questions into a glance rather than an investigation.

For individuals

Measure as little as possible. The honest signals that a person's system is working are that commitments are not being forgotten, that Waiting For items are being chased, and that the person can say what they are doing tomorrow. None of those need a dashboard, and turning personal task management into a reported metric reliably makes it worse.

Free Task Management Templates

The fastest way to move a repeating process off the task board is to start from a checklist that already has the steps. The three below cover the Scrum ceremonies most teams struggle to keep consistent and a daily operational routine of the kind that should never be a to-do item. Each opens as a template you can run immediately or edit in the template designer; the full library is at checkflow.io/templates.

Sprint Planning Checklist

Runs the planning session the same way every sprint: backlog refined, capacity calculated, sprint goal agreed and commitment recorded.

Sprint Review Checklist

Prepares the demo, invites the right stakeholders, captures feedback and feeds it back into the backlog at the end of every sprint.

Social Media Manager Daily Checklist

A daily operational routine — scheduling, monitoring, engagement and reporting — that runs on a schedule instead of living as a permanent to-do item.

How CheckFlow Fits

CheckFlow is built for the process layer described throughout this guide: the repeating work that belongs in checklists rather than on a task board. It does not replace a Kanban board or a sprint tool for one-off and project work — it takes the repeating half of the team's effort off that board and gives it the structure a task list cannot.

Every process starts as a template with steps, assignees and required fields, built in the template designer or picked from the library. From the template, runs are started by hand, on a recurring schedule (daily opening checks, a weekly report, the monthly close, a quarterly review) or by an event such as a new starter being added. Each step is assigned to a named person or role, so "the team" is never the owner of anything, and dynamic due dates are calculated from the run's start date or from the completion of an earlier step, so a checklist that starts on a Thursday has its deadlines shifted accordingly without anyone editing them.

Conditional logic shows or hides steps based on earlier answers, so one template can handle a contractor and a permanent employee, or a critical and a routine patch, without maintaining separate versions — the guide to conditional logic in checklists covers the patterns. For genuinely one-off work that does not warrant a template, CheckFlow also supports standalone tasks that can be assigned and tracked alongside checklist runs, so the team is not forced to keep a second tool for the odd item.

The real-time dashboard shows every active run, its assignee, its progress and anything overdue, which is what replaces the status-report stand-up and the "did you do that yet?" message. Every completed step is recorded with who did it and when, producing an audit trail per run that a task board never generates. And the Zapier integration and API let a card on your task board, a ticket in your helpdesk or a record in your HR system start a checklist run automatically, so the flow layer and the process layer talk to each other rather than being retyped.

CheckFlow's checklist software starts from $10 per user per month, with a 14-day free trial and no credit card required. You can see what live runs look like on the checklists page, and if you are comparing options the roundup of the best checklist apps sets out where CheckFlow sits against lighter personal tools.