Kanban, the hub of the system

So far, we have seen how to control what enters the system through inboxes, then how to reserve the calendar for things that must happen at a specific time. That leaves everything that is not directly tied to a time constraint: tasks you can choose to complete at different moments, depending on the context and your priorities.

In my opinion, that is the whole point of a productivity system. It should not merely store a list of things to do: it should help you choose the most relevant action at any given moment, without having to reconstruct your entire thought process every time. In short, it should help you make the best use of your energy.

The heart of my system is therefore a Kanban. If you have never heard of one, the basic idea could hardly be simpler: imagine sticky notes moving from one column to another as work progresses. The method originated in the Japanese automotive industry, but it adapts very well to personal organization and has become a staple of many organization systems.

The tool itself matters very little. Notion, Trello, Miro, and many other applications can all be used to build a perfectly adequate Kanban. Personally, I use an entirely custom system created through vibe coding, but that is absolutely not a requirement. Most tools on the market are flexible enough to implement what I am about to describe.

One important clarification before we begin: this is a personal productivity system. You can draw inspiration from it to organize a couple, a family, or a small team, but every rule in this article was designed primarily for one person. That changes many things, especially how contexts are defined and how you decide that a task is actionable.

Four examples to follow the system in action

To make these principles more concrete, I will use four tasks throughout the article:

• Organize Christmas dinner for ten people;
• Complete a data analysis project for a client;
• Do the weekly laundry;
• Install a shelf in the living room.

These examples are deliberately very different. Some are professional, others personal; some can be completed quickly, while others involve several steps and depend on people outside the system. Yet they can all be described and tracked using the same structure, which is precisely what makes the system so powerful.

What defines a task: the DoD

The smallest common unit in the system is the task. But a title alone is not always enough to understand what you are really trying to accomplish. “Laundry,” “shelf,” or “project XYZ” point you in a direction without clearly showing where the finish line is.

What truly defines a task is therefore its DoD, or Definition of Done. I keep this term from software development because it is short, widely understood, and describes exactly what we need: the concrete state in which the task can be considered complete.

A DoD can be very ambitious (“Move to Japan”) or very modest (“Clean out the fridge”). There is no need to feel self-conscious about it or worry that you are tackling something too large or too small. The only real question is: what will need to be true for me to say that this task is done?

Let us apply that question to our four examples:

• Instead of “organize Christmas dinner,” the DoD could be: “Dinner is on the table, the groceries have been put away, and the guests are seated.”
• Instead of “finish the analysis project,” you could write: “The client has approved the project completion email and the invoice has been paid.”
• Instead of “laundry,” the task becomes: “The clothes have been washed, dried, ironed, and put away, and there is enough detergent left for the next load.”
• Instead of “install a shelf,” you could be more precise: “The shelf is securely installed, the books and decorations are in place, the packaging has been taken to the recycling center, and the assembly instructions have been scanned and saved to the cloud.”

This definition is not an exhaustive plan. It does not require you to anticipate every step or every possible problem from the outset. It simply helps you foresee the general course of the task, understand where you are heading and, above all, avoid abandoning it at ninety percent because you forgot the finishing touches.

The DoD also helps identify tasks that are too broad. If the definition of “done” becomes endless or combines several independent outcomes, it may be worth creating several tasks. Conversely, there is no need to split every everyday action into ten separate cards. The right level of detail is the one that genuinely helps you move forward.

Sometimes the DoD will remain a little vague, especially when you are just beginning a subject you know little about. That is fine. You should still make the effort to formulate it using the information available, even if you refine it later. An imperfect definition is already more useful than a vague title you never quite know what to do with.

The task description

The DoD describes the destination; the description gathers the useful information you need along the way. You can keep all sorts of notes there: an idea, a constraint, an address, a summary of a conversation, a list of measurements, or the reasons behind a decision.

It is particularly useful to choose a tool that supports links, images, and possibly integration with Google Drive or a similar service. For the shelf task, for example, you could attach a photo of the wall, the available dimensions, and a link to the model you are considering. For the analysis project, you could keep a link to the shared folder and a note listing the main people involved.

The goal is not to recreate a storage system inside the Kanban. Large documents and reference files can remain in their usual home. The task should primarily serve as an entry point: when I open it, I should be able to recover the necessary context quickly and know where to find the resources I need.

You should also prevent the description from becoming a graveyard of notes. Outdated information can be deleted or clearly marked as such. An important decision deserves to be written down properly. The Kanban should reduce the effort required to resume a task, not increase it by forcing you to reread a confusing thirty-line conversation.

Status: the Kanban column

A task’s status is the column it currently sits in. My system uses simple statuses, but they need to be applied with a great deal of discipline. Here is a brief definition of each one before I go into more detail:

• Actionable: the next action that will move the task toward its DoD can be completed, or at least started, immediately. This does not mean it has to be done right away, only that nothing prevents it from being done.
• Snoozed: the task meets the same requirements as an actionable task, but it cannot or should not be resumed until a future date.
• Waiting: the task is blocked by another person, a delivery, a decision, or any other external factor.
• To archive: the DoD has been reached. The task is complete, but remains visible until the next archiving ritual.
• Next sprint: the task is not yet clear or mature enough to become actionable, but it is worth keeping for a future review.

This classification must describe reality, not your wishes. A task does not remain “Actionable” merely because it is important if, in practice, you are waiting for a response. Conversely, a task should not be placed in “Waiting” simply because you do not feel like dealing with it.

The value of the board comes precisely from this honesty. When I look at the “Actionable” column, I should be able to choose a task and begin without discovering a hidden condition a few seconds later.

Tasks in the “Actionable” column

An actionable task must first have a context. This is a central concept in my system. The context indicates with whom, where, or under what conditions the task can move forward.

The most obvious contexts look like “with a particular person,” “at home,” or “at the office.” They can also be more specific: “in the car” to group calls you can make during a journey, “with a computer” for tasks that cannot be completed from a phone, or “at the store” for several purchases you can make in the same place.

Personally, I also use a “brainstorming” context. It is neither a place nor a person, but more of a mental mode: it groups subjects I need to think through freely before deciding what comes next. This category works for me, but it will not necessarily be useful to someone else.

That is exactly why contexts are personal. They should reflect your life, your movements, your tools, and the way you work. Like inboxes, they will evolve over time. You can add one when a recurring need emerges and remove one when it no longer helps you make a useful choice. Your chosen tool should make these adjustments easy.

An actionable task must also contain a concrete next action. This is not about repeating the task title, but describing the next visible action that will move it forward. “Make progress on the project” is too vague; “email Thierry to ask him for the budget approved by the director” can be acted on immediately.

You can write down several actions in advance when the sequence is clear. There is nothing wrong with planning ahead a little. The first action remains the most important, however, because it is what makes the task truly actionable. If I do not know what the next action is, the card is not ready to remain in this column.

Once I have completed an action, I check it off. If another action can begin immediately, it becomes the next action. Otherwise, the task changes status: it might start waiting for a response, be postponed until a specific date, or move to the “To archive” column if its DoD has been reached.

I keep a history of past actions. It documents the work, helps recover information, and makes it easy to understand what has already been tried. This is particularly useful for long or professional tasks, but even a personal project can benefit from that record.

Optionally, I also add a “last action” date whenever I have made meaningful progress without completing the task. It is a good way to see which subjects have been active recently. When many things are open at once, this date is a reminder that several projects have genuinely moved forward even if none of them has yet reached its DoD.

For our four examples, the next actions might be:

• Christmas dinner: “Use AI to find a menu that accommodates the vegetarian requirements,” in the “With a computer” context.
• Analysis project: “Email Thierry to ask him for the budget approved by the director,” in the relevant computer or work context.
• Laundry: “Gather the clothes and start the washing machine,” in the “At home” context.
• Shelf: “Go to the hardware store,” in the “Business hours” or “At the store” context, depending on how you prefer to organize your filters.

Contexts do more than describe tasks. They let you filter the board according to your present situation. If I am at home for thirty minutes, I can display what is actionable there. If I am about to see someone, I can check the subjects I need to discuss with them. The Kanban stops being a long, abstract list and becomes a decision-making tool.

Tasks in the “Snoozed” column

The “Snoozed” status is a little unusual, but its principle is simple: the task is ready to be acted on, with a context and a next action, except that it should only reappear from a particular date onward.

This column prevents you from cluttering “Actionable” with tasks that are not relevant today. Without it, the board eventually presents cards that you have to read and then ignore over and over again. This repetition creates noise and reduces your trust in the system.

Ideally, an automation—which is fairly easy to set up in most tools on the market—moves the task from “Snoozed” to “Actionable” when the chosen date arrives. Postponing the task is not a way to forget about it: it is an explicit decision to make it visible again at the right time.

Here is how our examples might temporarily move into this column:

• Christmas dinner: the task is postponed until the day the dessert can be picked up from the caterer, since everything else has already been organized and scheduled.
• Analysis project: an interim meeting with the client is scheduled in five days, and the next action will necessarily depend on its outcome. The task can be snoozed until then instead of being checked every day.
• Laundry: once the clothes have been hung up, the task is postponed for twelve hours, when they should be dry and ready to iron.
• Shelf: if the purchase has deliberately been postponed until the sales begin, the card can reappear on that date.

I find it useful to sort this column by the date on which tasks will return to “Actionable.” This shows you what will reappear automatically and when. That small preview helps you anticipate the upcoming workload without cluttering the list of choices available now.

You should nevertheless avoid using “Snoozed” as an escape button. Postponing an uncomfortable task every week solves nothing. If a card keeps returning without moving forward, the problem may lie in its DoD, its next action, its context, or even its relevance. The system should then force a decision rather than perpetuate the delay indefinitely.

Tasks in the “Waiting” column

A task moves to “Waiting” when it cannot progress without something external. The most important point is to record the date it began waiting. This date shows how long the blockage has existed and helps you decide when a follow-up becomes necessary.

In my Kanban, I sort these tasks from the most recently blocked to the oldest. This makes it easy to follow the natural flow of conversations. You may prefer to bring the oldest to the top if your main goal is to identify long-running blockages; what matters is recording the date and using a consistent order.

You should also state clearly who or what you are waiting for. “Waiting” is not enough. A note such as “Waiting for Julien’s approval since July 12” makes the situation immediately clear and lets you follow up with the right person without rereading the entire card.

A waiting task no longer has an active context because you are no longer responsible for the next action. Its previous context can remain in the history if that helps document the work, but the task should no longer appear in filters for things you can do now.

Our examples produce some very familiar situations:

• Christmas dinner: the task is waiting for a cousin to confirm in the family WhatsApp group whether he eats certain vegetables.
• Analysis project: the task is waiting for Julien to confirm receipt of the report.
• Shelf: the chosen model is out of stock, and the task is waiting for an email from the store announcing that it is available again.

Laundry is less naturally suited to an external waiting scenario. If the washing machine breaks and a repair visit is scheduled, the task could be waiting for the technician. In the ordinary course of events, drying time belongs in “Snoozed” instead, since you know approximately when the next action will become possible again.

This distinction between “Snoozed” and “Waiting” matters. In the first case, a date primarily determines when the task returns. In the second, it is an external event whose timing is often uncertain. Confusing the two makes follow-ups and automations far less reliable.

Tasks in the “To archive” column

This is the simplest column: the DoD has been reached. Dinner has taken place, the client has approved the project and paid the invoice, the clothes have been put away, or the shelf has been completely installed. There is no next action left to define.

Yet I do not delete the task immediately. I put it in “To archive” for two reasons:

• It is always possible that I was mistaken. A task can return to “Actionable,” “Snoozed,” or “Waiting” if I discover that something is genuinely missing from its DoD.
• My system also relies on sprints. During a dedicated ritual, completed tasks are reviewed and then actually archived. I will explain how this works later.

I sort this column by completion date, from newest to oldest. It provides an immediate overview of the work completed since the last review. That is not merely satisfying: the list also lets you check that the stated outcomes are truly complete before they disappear from the current view.

The word “archive” matters. A completed task may contain useful decisions, links, or history. Keeping it allows you to recover the date of an action, the model you purchased, the person you contacted, or the way a problem was solved. There is no need to keep everything forever, but deleting by default throws away a memory that may have value.

The “Next sprint” column

The “Next sprint” column holds things that are not yet actionable, or even always perfectly clear, but that I do not want to forget. It acts as an intermediate zone between an idea captured in an inbox and a properly prepared task.

A card might remain there because its DoD still needs to be refined, because the project is not a priority in the current sprint, or because a decision will need to be made during the next review. It should not, however, pretend to be an actionable task: until its next action and context have been defined, it does not belong in the corresponding column.

This column will be handled during a sprint review ritual. Each item must then receive a clear outcome: be prepared and made actionable, be postponed, return to an inbox if more thought is needed, or be abandoned if it is no longer worthwhile.

I will return to sprints and their rituals in detail in another article. For now, it is enough to remember that “Next sprint” is not a permanent dumping ground. It is a queue intended to be reviewed at a specific time.

Bonus: should you separate work and personal life?

Personally, I use a single Kanban for both professional and personal tasks. I have added a specific field, separate from contexts, that lets me filter either side of my life instantly.

This logical separation seems more practical to me than two completely independent systems. I only have one pool of attention: a personal constraint can affect my working day, and a professional deadline can reduce the time available at home. A shared view therefore lets me make choices with the whole situation in mind.

That said, there is no absolute rule. You may need two separate Kanbans for reasons of confidentiality, access rights, integration with company tools, or simply personal preference. That is not a problem. In that case, at least try to keep the rules consistent across both systems and maintain a simple way to get an overview when you need one.

The “professional or personal” field does not replace contexts. “Professional” describes an area of life; “with Thierry,” “at the office,” or “with a computer” describe the conditions under which an action can move forward. Mixing those two dimensions produces less useful filters.

In summary

An effective personal Kanban does not rely on a large number of columns or a sophisticated tool. It relies on a few distinctions maintained with discipline.

Every task should clearly express the expected outcome through its DoD. If it is actionable, it should have a concrete next action and a relevant context. If it cannot move forward, the board should explain why: a future date, an external dependency, or a need for clarification during the next sprint.

Movement between columns matters just as much as the content of the cards. After every meaningful action, you should ask whether the task is still actionable, whether it is now waiting for something, whether it should be postponed, or whether its DoD has been reached. This regular updating is what keeps the board reliable.

Once this way of working becomes natural, the Kanban truly acts as the hub. Inboxes feed the system, the calendar protects committed time, and the board presents the work that can move forward. You are no longer choosing from an undifferentiated list of things to do: you are choosing among actions that are genuinely possible in your present context.