Previously I described how input could come into our world and the tools that store them, OmniFocus and Freemind.

Flow 1 – processing something for dealing with later

The most common flow of all – there’s something on you to do but it can’t be dealt with now.

The most common reason for this is usually that it’s going to take longer than 2 mins.

Looking at the diagram, the section marked “Do It! near the centre.

So if a task will take longer than the 2 minute window, then we enter a task in OmniFocus for later on. The reason behind all of this is simply efficiency. By separating batches of gathering inputs from processing actions we avoid all of the inefficiencies of context switching.

Let’s say we’ve just remembered that in order to move our “Upgrade Server” project along, we need to speak to a colleague Ann, to get the current credentials. In this instance, it’s a “do as soon as I can” job.

First, the task comes into our head, the inbox is the first port of call. We’ve immediately identified what it is, namely “Get Credentials from Ann”.

The inbox is the first port call for all our new input.

Almost instantly, we’ve also identified that this task is just one step towards getting the server upgraded. In GTD world, anything with more than one step is a project, so the task is assigned to the “Upgrade Server” project.

Very quickly, we’ll categorise tasks that contribute to project completion.

To flesh this out, let’s say seconds later, adding that task had triggered a thought that we’d also need to skill up on Tomcat, which this server happens to be running, we’d then follow the exact same steps. Using OmniFocus to drill into the project view, we’d now see:

The project view gives us all the steps that are outstanding to finish a project.

Why is the cutoff two mins?

David Allen deems 2 mins to be the amount of time to classify something in terms of the action, any project in contributes to, how to store the info so you can get it back, and setting any appropriate deadline. If it takes less than 2 mins to just complete the task, you might as well as do it there and then and get on with your day.

There is one exception to this rule, and that’s if the task takes less than 2 mins, but can’t be done right now. As a trivial example, you needed to return a USB cable to a colleague, but when you’re processing your inputs you’re working from home.

It won’t take 2 mins to return the item, but you do need to be physically co-located. In this instance, you’d follow the same flow of capturing the task in OmniFocus since you still want to capture the thought and not constantly having it nagging away at you.

What if the action is standalone, not part of a project?

Remember here the definition of project as ‘anything that takes more than one step to be done’. Looking at the GTD diagram agains, towards the bottom, there is a list of “Next Actions”. I personally model this is in OmniFocus as a ‘pseudo project’ called Sprint Misc.

I do this because I don’t want tasks that have already been classified clogging up my inbox. Anything action that’s currently in there should be representative of the fact that I haven’t decided ‘what it is’ yet.

If we build on the example previously given, I need to give Steve back his USB cable at my earliest possible convenience. By using a project of “Sprint Misc” as my “Next Actions” list, I can get it out of my Inbox into a place where all my ‘single-step actions’ go.

Let’s move onto dealing with inputs that have a time element to them.

One thought on “A GTD Sprint example using OmniFocus and Freemind”
  1. […] paper is fine), you need a way of storing both your workflow and support materials. At work I use OmniFocus and Freemind but there are a heap of tools that you could use. Do you have a favoured set of tools? Mention it […]

Comments are closed.