Next Action Granularity for Research and Debugging

[ArcCaster]

Suppose you work in the software industry, and your job is to research and debug new software. My problem is that research takes me in many unpredictable directions, and debugging is even more unpredictable -- so it is difficult to get very granular with next actions. On the other hand, if you just define an action item as 'debug feature x', you may have an action item that takes days, which is not as granular as I would like it.

What approach would you suggest that would give me sharp easily-visualizable next actions of the correct granularity?

 

[jknecht]

In this case, 'debug feature x' is a project.

You don't have to plan the whole project before you start, you just have to know what the very next action is.

For example, when this project first comes up, the next action is probably "See if the bug can be reproduced in cleanroom environment". You do the next action, which will probably lead to other actions (which do not necessarily have to be recorded unless you are interrupted or need to stop for some reason). When lunch-time arrives, you might know that the next thing you were going to do was "download the logs from the cleanroom servers". Write that down -- it is your next action.

This allows you to be very fluid in the project without losing your place when you have to take a break. Think of the 'next action' as a bookmark.

 

[Brent]

Well put, jknecht!

In terms of wording Next Actions, I find it most helpful to phrase them as physical actions. "Debug" is too vague; what exactly do I have to look at? Perhaps, "Add print statements in move() function to see why ships aren't moving" The NA needs to specifically describe what I'm going to do. What will I type? What web site will I go to (even if it's just Google)?

 

[Jamie Elis]

n/a is just a cue for you

Keep in mind that the n/a you write down is just a cue for you and you alone so you have enough information to take the next step (s) on a project.

Between predictaible sequences, a next action might be identifying or committing to a working on the project for reasonable amount of time (for your stamina and customers' needs), with the appropriate "tools", information and materials at hand, and maybe in a certain location.

 

[ArcCaster]

Thanks -- this really helps me to see the borders tween projects and action items. It looks like I could have projects that might be only a few hours, or even a few minutes, long.

Does this mean that, when I plan my day, I put 'debug feature x' in my projects list, put 'stud file x with printf statements' in my action list, and, if I get interrupted, capture the next action somewhere (on paper in my inbasket, or in my word todo file, which I generally leave open)?

And, when the debugging is done, what then? I am accustomed to just putting an X in front of all done items in Word, sorting them so they fall to the bottom of the list, and referring to them when I write weekly reports. Having the project in a separate file kinda complicates things because I am not used to tracking projects that are so short, and that can open and close in a day.

 

[Rolf F. Katzenberger]

Unit Tests as Next Actions

Does this mean that, when I plan my day, I put 'debug feature x' in my projects list, put 'stud file x with printf statements' in my action list, and, if I get interrupted, capture the next action somewhere (on paper in my inbasket, or in my word todo file, which I generally leave open)?

With respect to debugging work:

Instead of "stud file x with printf statements", you might consider writing a single unit test method and making it run as your next action. That's very concrete work that can be done in one sitting, plus it is focussed more on getting closer to a working feature than on "poking around".

Rolf

 

[kewms]

I'm not a programmer, but writing is similar in that the components of a project can be big, amorphous, and difficult to break down into granular chunks.

I've found that it helps to break writing projects down into chunks of between 3000 and 5000 words. In part that's because many of my projects are that length to begin with, but for larger projects that's still about the biggest piece that I can get my head around at once. 3000 words is definitely project-sized, as it's substantially more work than I can complete in a day or (usually) even a week. But it's still small enough that I can visualize the end and see myself making measurable progress toward it.

For a programmer, the equivalent-sized chunk might be one module (or sub-module) of a complete system, or one menu item or group of menu items. So you might have a subproject that is something like "feature x behaves as specified, with interfaces complete."

For a 3000-word chunk of a writing project, the next action is likely to be "call Joe Source to schedule interview," or "browse research file on Topic," or "sketch mind map: what do I know about Topic?" For a programming project it might be "test feature X, see if text still blinking," or "trace feature X for memory leaks," or whatever. (Like I said, I'm not a programmer.)

My point is that it seems to me that "debug feature x" doesn't work well as either an NA or a project. It's not an NA because it's too vague, and also not granular enough. It's not a project because it doesn't have a clearly defined outcome: how do you know when you are done?

In general, I wouldn't recommend creating project items for something that will only take a few minutes, unless you know that the minutes will be spread out over a longer period. That sounds like a good way to spend more time maintaining your system rather than actually using it. There are exceptions, but for your example of programming tasks I would recommend using larger project chunks and working on your NA definitions.

On preview: On further reflection, might you be confusing projects and calendar items? As you plan your day, you certainly might want to block out time to debug feature x, but you probably can't know in advance that feature x will be working at the end of that time.

Hope this helps,

Katherine

 

[jknecht]

Does this mean that, when I plan my day, I put 'debug feature x' in my projects list, put 'stud file x with printf statements' in my action list, and, if I get interrupted, capture the next action somewhere?

I would definitely put 'debug feature x' on your project list. If 'stud file x with printf statements' is the very next thing you can possibly do, then it goes on your 'Next Actions' list.

Interruptions, though, are tricky business. If you haven't completed your printf's, then you don't check off the next action and you don't create a new one. Though, you might change the next action to "finish putting printf's in file x", but only if there is a chance that you'll forget that you've already started.

If you've completed the next action and are well on to other things when the interruption comes, then you should mark the "printf" action complete and write down the new next action (for example, "run regression tests on component x").

(on paper in my inbasket, or in my word todo file, which I generally leave open)?

It's your choice of where you capture this. Me? I just put it directly into my next actions list. There's no sense letting it linger in my inbox until the next weekly review if I know exactly what it is and how I want to process it right now.

Not to derail the conversation, but your "todo" file worries me a little bit. Is this a list of your projects, or your next actions? I sense some ambiguity here, but maybe it's just a matter of terminology. If you've got your projects and their next actions comingled, you really should consider separating them... even if that just means putting headers or page breaks between them.

And, when the debugging is done, what then? I am accustomed to just putting an X in front of all done items in Word, sorting them so they fall to the bottom of the list, and referring to them when I write weekly reports. Having the project in a separate file kinda complicates things because I am not used to tracking projects that are so short, and that can open and close in a day.

Again, I'm not clear on what an "item" is in your Word document. I don't want to make any suggestions about where to put your X's and how to sort without understanding whether you keep your project lists separated from next actions.

That said, I suggest you keep a separate daily log of things you've done (for purposes of reporting to management). Management is likely to want information at an entirely different level from the way you'll need to structure things in GTD.

In my experience, GTD is fabulous for keeping my work on-track; not so great for status reporting. It's far too granular, and the next actions really only represent what I need to do after each time I stop -- it's not a complete list of everything I've done, nor even the "important" things I've done.

Hope this helps.