Using GTD ® in a Sprint – a worked Example

So here, I’m going to go through an example of using GTD ® in a sprint. The purpose of this is to show how the principles of GTD can apply to a software development. 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.

Using GTD ® in a Sprint -the original flow diagram for reference
A reminder of the classification system we’ll use to organise anything and everything.

Different Tools for Different Inputs

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 and reference info, this is where a mind-mapping tool like Freemind comes in.

For the purposes of this example, we’ll only use these to tools to distinguish between a workflow tool and a tool for reference data. There are definitely more places to store reference data (the file system and email to name but two). But we’ll just focus on two systems for now.

Our Simplified Sprint

Before we can start using GTD ® in a sprint, let’s look at our current setup for the next 2 (fictional) weeks. I have stripped OmniFocus down to show just a view where we have an inbox and a sprint with 3 projects.

Using GTD ® in a Sprint - OmniFocus perspective of a simple sprint

Initially our projects are empty, but as we process different inputs we’ll see that change.

Freemind is just a simple supporting document, with the 3 projects:

Using GTD ® in a Sprint - Freemind is used for reference data

Understanding GTD Input

During our fictional sprint, we can get input from a variety of sources:

  • Our own ideas
  • Slack/Other instant messaging tools
  • Emails
  • Website links

but they’ll all end up in one of 3 places:

  • OmniFocus if they’re an action
  • FreeMind if they’re not actionable but useful information
  • The bin if they’re neither of those things

When not to process something

In some cases though, when you wouldn’t process something. This would be 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. This relates to “Do It!” on the original workflow diagram. 
  • When you’ve identified this the item will never be relevant to you, then you eliminate it. This corresponds to the trashcan you see in the original diagram on the top right.

Let’s move onto different use cases and how they relate to our sprint. 

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 there 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

The biggest challenge I’ve found in using GTD ® in a sprint comes from when tasks require other people to carry them out. 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 critical something actually is. More examples of that in a future post.

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

Batching your flows

In using GTD ® in a sprint, you have a methodology that aligns quite nicely to the processes you should be following as team anyway. Not only that, as an individual, you’ll see huge gains value in productivity 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.

If you want a more specific example, and you use OmniFocus, you can check that example next.