A GTD Sprint example

James Bowen
5 min readAug 6, 2018

So here, I’m going to go through a sprint example using GTD ®. The purpose of this is to show how the principles of GTD can apply to a real world example. Some of the data with actual people’s names etc is blurred out, but the underlying principles will still be apparent, each kind of ‘external input’ will be translated into a GTD input.

Tools

As I use a Mac at work, I’ve opted for OmniFocus and Freemind. The choice of tools is a matter of personal preference, although I found OmniFocus fits my needs. The point is there are two kinds of tool:

  • A tool to capture the day-to-day workflow, this is where OmniFocus comes in.
  • A tool to support creative thinking, this is where a mind-mapping tool like Freemind comes in.

With regard to the latter, supporting material can also be in the forms of email, text files, images etc, but I find mapping a great way of ‘offloading’ thoughts.

The five flows of GTD

I’m using a sample snippet from a sprint to show how there are five broad categories for you to use to process the things that come at you. I’m using email as the input mechanism for the sake of a video, but bear in mind, slack, face to face conversations and the like are exactly the same. The purpose of the video is to show you how to ‘funnel’ all this info into the same trusted places.

When you wouldn’t process input

Before I dive into the examples below, recall the overall flow diagram. There are two candidates that don’t make the cut for entering your ‘second brain’.

  • When the action can be done, there and then, in under 2 minutes — in this case the overhead of processing and retrieving isn’t worth it.
  • When you’ve identified this the item will never be relevant to you, then you delete it.

Batching your flows

The point I am trying to get across is the value in productivity that you gain when you batch your flows. You have different sweeps for the ‘gathering’ of your input’, ‘translating’ it, and ‘prioritising’ it. This might seem convoluted at first, but once you get adept, you’ll find your clarity greatly improves, and you can do this very quickly at any suitable point of the day.

Flow 1 — processing something for dealing with later

The most common flow of all — you have something to do, but it will take more than 2 minutes. So I quickly scan the email, work out that I need to do something but there’s no precise date on it. I categorise it according to the project that it belongs to and convert it into a task for OmniFocus.

A word here on precise date — by this, I mean that it doesn’t have to be done on exactly that date, just as soon as possible. Obviously we’re all working to deadlines, but the calendar should be sacred territory in GTD. If you assign a date to something it, that should have meaning.

Also remember here the definition of project as ‘anything that takes more than one step to be done’. I actually have a dummy project of ‘Sprint Misc’ for things that are on the radar for a two week block, but have only one step.

Flow 2 — dealing with time-sensitive input

Sometimes there will be something that happens on a specific date, in the example given here, an external vendor completed an upgrade over a given weekend, requiring our team to regression test it. There is no point starting before a certain date, so I assign a start date of the Monday following the upgrade. This actually illustrates an important concept wrt GTD — the time I identify a task is completely de-coupled from the time it’s appropriate to do it.

In the case of time sensitive inputs tere are 3 kinds to think about:

  • Ones that have to happen only on a certain date — i.e a meeting. There’s no point attending these a day early, or a day late.
  • Things that have to finish by a certain date — I rarely assign due dates to tasks as it’s implicit from the sprint commitment.
  • Things that cannot start before a certain date — such as regression testing an upgrade that is due to happen.

Flow 3 — Reference material

Not all input are actions, but the world isn’t kind enough to neatly categorise things for us in advance. Information that is not actionable, but merely supported needs to get stored off for later use. The key thing is to have a place to go that you can access what you need.

In a recent seminar I attended featuring speakers from Evernote, it was estimated that time to retrieve/search for information loses us around 2.5 hours a day! I was shocked at this stat, and pleased that I had already worked out to alleviate some of this by having consistent places to store my information.

In addition, I have found Freemind to be a valuable tool to organise my thoughts for a sprint, and link off to files on my local drive. There are plenty of uses for mind-mapping, when you’re new to a sprint, it can be helpful to understand what the team objectives are, or to learn the domain you’re working in. As your competence in one area grows, your mindmaps can adapt to support your workflows.

Flow 4 — delegating work to other people

Some tasks during a sprint require other people to carry them out of course. The challenge then becomes how we keep track of that. GTD has the idea of contexts, and one of those contexts can be ‘Waiting’, to signify that we are dependent on someone else. In this example, I’ve set up some exchange rules to automatically create a copy of any message I send to a ‘Waiting Folder’.

The logic behind this is that if I send a mail at work, chances are it’s for some action that needs to happen. At the very least it will be the exception for this not to be the case. This way, when I check my email, I can see at a glance whether I’m waiting on anyone for anything. If I don’t get a reply by the next time I review my emails, I can really quickly import this into OmniFocus as a task with a context of waiting. Usually though, I’ll get a reply by then.

Likewise, if I’m using slack to send a message, I can set reminders for a follow up.

Flow 5 — sorting your tasks and planning your day

Once you have your inputs gathered, you have two steps. Assigning tasks to projects (a sorted list of steps to get to a desired outcome), then sorting the tasks within those projects.

This way I have a horizontal (all the projects in my world) and a vertical view (all the steps to see a project through to completion).

Whilst I’m ordering tasks, I set appropriate dates depending on how time ciritial something actually is. More examples of that in a future post.

GTD® and Getting Things Done® are registered trademarks of the David Allen Company.

Originally published at https://www.learncoderetain.com on August 6, 2018.

--

--