When you've taken every open loop, and dump it onto a piece of paper, you may be surprised to see that you have many more to-do items than you expected. I suspect that those with few items on their checklist are holding less (or more) important tasks in the recesses of their mind, possibly a sign of distrust in their capture system. Either way, not ideal. Coincidentally, the benefits of having a separate processing step become obvious when the number of items on your checklist grows huge.

Faced with many tasks, how do you then pick the right task to do first? You'd have to glance through the whole list, and pick the task you think is best at the time. What you're subconsciously doing here is mentally processing all these items.

This is why I (and David Allen) recommend extracting this processing step out. We subconsciously do it anyway, why not make this step explicit, and do this step only once per task?

Processing is all about:

1. making tasks actionable, and
2. giving tasks enough context to help me decide what's the next right task to tackle

To make tasks actionable, David Allen recommends using verbs to preface all to-do items during this step. I skip this because in my line of work the actions are pretty obvious. For example, if the inbox item was a link, the action would be to read through the linked item. However, if the captured inbox item is a large task that can be broken down into smaller tasks, I may delete the task and replace them with smaller tasks.

Next, what kind of context helps me decide on what to work on next? Some useful context cues are:

1. Priority: How important is it for me to get this done?
2. Location: Where can I do this task? Perhaps only at home, or in school, or at the office.
3. Effort Estimate: If I only have 30 minutes of available time remaining, I'd prefer to work on tasks that take an estimate of no more than 30 minutes, than embark on a large task that I would have to pause on.
4. Project: If this task belongs to a particular project, it helps to group/classify these tasks so I can work on clearing related tasks together.
5. Date: Perhaps this task has a due date, or can only be performed on a specific date.

Perhaps more contextual information can be added, but I find that these 5 are sufficient for my needs.

This is highly subjective, but I find that this is a task I can do without deep thinking. Hence, I find myself processing my inbox when taking breaks from deep work, but more often than not in the morning and night when I am starting or ending my day.

Typically the first thing I do when I process my inbox is to schedule the task, or add a deadline to a task, where necessary. Allow me to explain a little on their significance.

A scheduled task is a task that I absolutely have to do on that specific day, on that specific time. Such tasks include appointments (with friends, or the doctor), and often appear on the calendar. Most often, I transfer these tasks to Google Calendar, and use org-gcal to make the items visible in my birds-eye view. Your calendar is sacred! Do not make the mistake of scheduling tasks that do not absolutely have to be done on that time.

There are, however, tasks that have to be done by some time. Common examples of such tasks include homework, or bill payments. Org-mode supports tagging tasks with deadlines, and such deadlines also appear in the birds-eye agenda view.

I first look through each task and schedule the task, or add a deadline to the task. Here's a demonstration of the sweet visual interface for adding a deadline to a task in org-mode:

Figure 1: Adding a deadline to an item

I thought I'd leave code out of this series, but I want to give a little teaser into how easy it is to set this all up in Org-mode's org-agenda. Here's the function I call to process each inbox item:

(defun jethro/org-agenda-process-inbox-item ()
 "Process a single item in the org-agenda."
 (org-with-wide-buffer
 (org-agenda-set-tags)
 (org-agenda-priority)
 (call-interactively 'jethro/my-org-agenda-set-effort)
 (org-agenda-refile nil nil t)))

Perhaps the technical reader can guess what the function does. Here's a little GIF showing me processing real tasks (I don't have much to hide).

Figure 2: Processing inbox entries

Let's walk through it step-by-step.

1. Give the task some location context. Tagging the task with tags @school and @home means I can work on this task both at school and at home.
2. Give the task a priority level, between A, B, and C. Here's how I decide a priority. It's a pretty loose dichotomy, but works for me.
   • A: Tasks that must get done regardless.
   • B: Tasks that should get done, but only after Priority A tasks.
   • C: Tasks that are good to get done, but not compulsory.
3. Give the task an effort estimate. This is in the format HH:MM, if the task is estimated to take days, perhaps it needs to be broken down further.
4. Refile the item. Here my tasks get assigned to the FYP project, because the readings are related to my Final Year Research project.

That's it! Make it a habit to bring your inbox count to 0, items are no use left in the inbox.

With everything processed, let's take a look at the agenda view:

Figure 3: The Org-Agenda View

There are 5 main components:

The Day Agenda

this shows tasks scheduled for the day, as well as time spent on tasks for the day. The agenda for different days can be shown, and the agenda for the week, or even the year.

Deadlines

Below the day agenda are all upcoming deadlines.

In Progress

This shows tasks that are in-progress, or are currently incomplete

Project Tasks

Tasks that belong to a particular project.

Next Tasks

Tasks that are standalone.

I bind this page to a convenient hotkey, so I'll always have a nice overview of my day's schedule, what I've accomplished thus far, and what's left to do. A simplified version of this agenda view can be found in this gist, but if you're interested in all the gory details feel free to pour through my emacs config.

Because we've gone through the trouble of processing our tasks, choosing a task becomes formulaic. Here's the formula I use:

1. Filter by location context (e.g. if I'm at home, show only tasks tagged with @home).
2. If I have time constraints, filter by effort estimate.
3. Is there a task scheduled for today that is undone? If so, pick this one.
4. Is there a Priority A task with an urgent deadline? If so, pick this one.
5. Pick a high priority task from the same project if the previous task done was from this project, else pick any high priority task.

Once I've picked a task to work on, I go to that line and press i to clock-in. This allows me to track where I spend my time. As a side benefit, I get better at estimating how long each task takes, by observing the total time I spent on previous similar tasks. Example of tasks that have been tracked can be seen in the agenda view above. This information also comes in handy when doing the weekly reviews that David Allen recommends in GTD.

I conduct a quick, weekly review every Sunday. During my weekly review, I:

1. Look at where all my time went, and think about whether things could've gone better.
2. Study the next week's agenda: look at any important scheduled tasks or deadlines, and decide whether any preparatory work will need to be done.
3. Relook some of the more recently processed tasks. Task priorities may change as time progresses, and it is possible that with a huge onslaught of new tasks, some important, older tasks may be left incubating. It's also possible that some tasks are no longer necessary.

That's all there is to the task management system. The vanilla GTD system is much more prescriptive, what I've done is to simply pick out certain parts that have been useful and easy to implement in org-mode.

In the final part of the series, I describe my org-mode powered Zettelkasten system.