Adding estimated time to complete to NAs

I was thinking of adding estimated times to complete an NA to my NAs. Is anyone doing this. It seems like it would be easier to scan your list and pick off certain NAs that might fit an available time configuration.

For example,

@Home
* Clean pool
* Mow yard

Would now become:

@Home
*Clean pool (45mins)
* Mow yard (2hours)

So if I know I only have a 1 hour block, I quickly identify Clean pool as my NA to complete. I think adding an estimated time to completion might help in clearing up some of the fuzzy NAs that make it to my list every once in a while. If I have an NA that is several hours long, chances are, I can break that down further into smaller NAs.

Thoughts?

Mike
 
It's one of those granularity issues. If that level of detail helps you to be more effective, then go for it! If it becomes more trouble than it's worth, don't bother with it.
 
I think it could be a great way to match NA's and available time.

In the book "Time Management From the Inside Out"
Julie Morgenstern talks about sudden opportunity lists and time estimation of tasks

You track/determine how long various tasks take to complete.

Then you create lists of tasks for whatever time length you like (15min, 30min, 60min etc). Each list is a "sudden opportunity list". If you have 30 min free you can pick something from the 30 minute sudden opportunity list to do.

I think her approach fits pretty well with GTD. You could further subdivide the sudden op list by context, or as you're doing add time estimates to NA's in your context lists.

I also like her concept of the time map. I think of it as blocking out time each week for every context.
 
Adding Time to NAs

I tried adding time and wound up deciding only to do it when the time required was particularly short (I define as less than 15 minutes) or particularly long (over 2 hours), so I can handle/plan accordingly. Everything in between I stopped noting time required as I felt I was spending too much time trying to decide whether something was a 30 min or 45 min item, etc. etc. YMMV.

Janice
 
I did that briefly, but decided to drop it. I think adding any steps or complexity to the system should be avoided unless there is a clear benefit.

I found that I already had an intuitive understanding of the time and energy it takes to "clean the pool" vs. "mow the lawn" just by looking at those task descriptions, so writing the times down didn't add value for me.

You may find that it really helps you, though.

One similar thing I did was time myself doing certain kinds of tasks so that I did gain an objective measure of the time it takes and in some cases decided to cut that time down by doing them faster or less perfectly.

Good luck.
 
What I'm trying to avoid is continuously scanning my lists and having to think about how much time a NA will take each time I look at the list of NAs, knowing I have a block of XX time I can make use of now.

Cleaning the pool and Mowing the yard might not be good examples, but for those NAs that are not so intuitive, your brain has to click into evaluation mode to grasp the time involved.

I want to be able to immediately zero in on those that fit the configuration. Maybe 15 minute intervals is too granular. Maybe 3 categories...15 minutes or less, 1 hour or less, 3 hours or less.

Thanks for all the feedback.

Mike
 
I like this last idea with the three categories.

Sometimes we don't know how long it takes to actually do things. I used to think emptying the dishwasher took 15 minutes. It actually takes 2 minutes or less. But emptying the dishwasher and reloading the dishwasher and cleaning the kitchen counters and sweeping the kitchen floor takes about 15 minutes. It helps to get straight exactly how long tasks take.
 
DoubleDippin said:
... but for those NAs that are not so intuitive, your brain has to click into evaluation mode to grasp the time involved. ...

Your idea fits a core principle of GTD: do your evaluation up front and capture the results in a way that is useful later when selecting and executing N/As. Definitely try it.
 
I also noticed the idea in the Julie Morgenstern book about listing the time it'll take to complete each next action.

Contrary to an earlier comment, I don't consider this an "extra level of complexity". Rather, it's makes it easier to assess my lists in terms of DA's second criteria for "Do" decisions: available time. Context-based NA lists only address the first criteria. The third and fourth criteria (energy level and personal payoff) obviously change constantly.

If I have ten minutes, I don't want to waste time sifting through a bunch of thirty and sixty minute things on my lists to find the ten minute things.

Finally, the way I executed this on my PDA was exactly as proposed above, that is with priority codes. Priority 1 was 60 mins.

When I started using Planner Pads, I just wrote in the estimated time (although still rounded up or down in 15 minute intervals).
 
Estimation trick

I find this information useful when skimming my NextActions list and I have such a field, but also didn't want to spend lots of time guessing whether something would be a 30 min or a 45 min task. So I use what could be called 1-2-5 estimation for tasks and projects, where the allowed values are 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, etc. It only takes me a few seconds to tell if something will take closer to 2 hours or to 5 hours. But it works for me because I don't need more accuracy.
 
I've tried doing this when I see a my Next Actions growing in particular context. It helps me to feel less overwhelmed if I see that I have 25 or 30 NAs but the sum of the time to do them would be 4-6 hours. I may not carve out the entire 4-6 hours but it just helps me to feel like the it is attainable.

In the end some NAs may take longer some may take less time than I estimated. I don't do it all the time. It's just one of those "tricks" to get me jump started.

Dave
 
Top