How to properly organize backlog tasks?

OmniFocus
#1

Hey guys,

I have been dealing with this inconsistency for months.
How should I organize backlog tasks with no project yet?

I like to consider projects as a set of tasks with a defined outcome to be finished on an estimated time.
I don’t want to use projects as generic containers of tasks.

So lets say that I’m working on project “Project A - V1” and there is an idea or task I want to capture related with “Project A” (but not for V1, maybe this is something I will be able to execute on V2 or V3).

What is the correct way to capture and organize this task so it will be available in my backlog for “Project A - V2” or V3 when created?

Thanks!

#2

There is no “correct” way. There is a way that is most comfortable for you. Consider that you have already said …

When anyone would however tell you that this is the “correct” way, I guess you’d be lost.

Indeed, I would create a Project that is just container of tasks (though not a “generic” one). In your case, in the same Folder as the Project A - V1, create a Project called Project A - Next Steps. Dump the ideas in this Project. Perhaps organize the ideas by a month/year Action group headings. This way, you can return and discover whether you had a cluster of ideas four months ago that never got implemented or should be discarded by now.

–
JJW

2 Likes
#3

In my workflow, I have a folder. My first project is the Phase 1 project. This project’s status is set to active. Then I have other projects called Phase 2, Phase 3, Phase 4. All of these other projects have a project status of On Hold. I dump all of my new ideas that are appropriate for Phase 2 into the Phase 2 folder. I might have some ideas for Phase 3 and put next actions into Phase 3. i won’t work on Phase 2 and Phase 3 until I’ve finished Phase 1. When Phase 1 is finished, I’ll set Phase 2 project status to active.

During my weekly reviews, I might go through a brainstorming session to see what I can do to flesh out Phase 2 next actions more clearly. I’ll revise Phase 2 actions based on the results of Phase 1. I might delete some next actions. I might rewrite or clarify some next actions. I might put some Phase 2 ideas into Phase 3. This will take time to redefine things.

As @DrJJWMac states, there isn’t any one correct way except what makes sense to you. But sometimes it takes some exploring in the beginning to figure out what makes sense to you.

For me, I’ll break a huge project into smaller projects inside a folder. Each project clearly holds a different phase for me. I’m no longer intimidated by seeing one big project full of ideas (dumping ground) and real next actions.

You might also just have an On Hold project called "Project Ideas and set the status to On Hold. When you do a weekly review of this project, you can try to redefine or clarify the true next action and then move it to the Active project.

3 Likes
#4

Thanks for your input guys. Some thoughts:

I totally agree there is no “correct” way. But considering a project a never ending set of tasks and the consequent lack of “achievement” may have a negative impact on the perception of being productive.
This is more-or-less solved on agile methodologies by implementing sprints. Something no present in GTD.

I have been using a workaround very similar to the one proposed by @wilsonng. But instead of using On Hold projects I have been using a deferred project. Which is quite the same.

Thanks again.

1 Like
#5

My team at work works in agile as well. One of the things I recently realized I was doing was keeping “monolithic” projects in OF and trying to organize tasks around them, like projects that didn’t change very often, because they would take multiple sprints to complete. So my project list used to look like:

* Website X
* Website Y
* Website Z

While that kept my project list short, it didn’t really serve me well as a bucket of tasks, because the list of tasks that looking at a project would generate would be all over the place (many contexts, many states), and relating to a myriad of different deliverables.

Also, in GTD speak, this meant that I was using OF projects more as Areas of Focus (20,000 foot) instead of as Projects (10,000 foot).

Now, I have significantly changed my approach to have many more projects that open/close much more frequently, but that relate to much more specific commitments/outcomes. My project list now looks like:

* Build the template for Page A of Website X
* Classify/plan outstanding requests from the business
* Refactor CSS for Website Z

In this way, the projects are not just buckets of tasks that kind of relate to each other, but are actual completable things, and I give myself permission to create and close projects daily (though I make most of them as part of sprint planning at the top of a sprint).

I have an on hold context called Someday/Maybe that I can use as a backlog, though I do keep a few other lists (single action projects) as support for my workflow:

* Project Concepts (held as tasks, but represent potential future projects)
* Properties (again, held as tasks, but actually a reviewable list of what was my project list)

So, while I haven’t really answered your question, @lgrassini, I hope my experience with the problem might help think of the problem in other ways?

Cheers,

ScottyJ

5 Likes
#6

Hi, my suggestion would be to keep only currently actionable tasks (or projects) in Omnifocus. Storing all ideas and potentialities within Omnifocus makes weekly reviews (or any kind of review) slow, and in my experience pretty overwhelming, due to the mire of stuff you have to wade through.

Instead, my suggestion would be to remove from Omnifocus all Someday/Maybe tasks, ideas for future projects and everything currently non-actionable (beyond the horizon of a week or 2) and storing them in a central notes repository. The specific implementation I am thinking of uses nvALT and 1Writer, as described here.

This will allow you to capture ideas from any device and store them all in a central repository. The process is quick and efficient, (in my experience as quick as the Quick Entry tool in Omnifocus). The search is also very quick and forgiving, allowing you to retrieve the information with ease when it’s time to convert a previously captured idea into a project in Omnifocus, for example.

For me, pruning Omnifocus in this way and using it only to help stay on top of currently active tasks and projects has been remarkable. Reviewing the system is immensely quicker (and therefore I engage in it more) and there’s significantly less decision fatigue involved during the review process due to the drastic reduction of hidden and on-hold tasks. Ultimately I’ve found everything more streamlined and ‘lightweight’ as well as a marked increase in trust in the system, serene productivity and an overall sense of control.

Anyway, as JJWMac says, there is no ‘correct’ implementation though perhaps this suggestion will point you in a useful direction.

To reiterate, the nvALT / 1Writer note set up can be viewed here.

3 Likes
#7

Hi, @deturbulence, Same situation here.
I interact with the team trough agile. Dealing with this 2 different paradigms (scrum vs gtd) on a daily basis it brings some friction.

I’m arriving to the conclusion that the way to go, for me, is using a folder in OmniFocus as the representation of the project on agile (JIRA in this case). And having projects inside this folder as representation of the current sprint.

Having a clear outcome and measure is essential to me, to my cognitive conception of “a project”.

Then, also, I’m keeping (as suggested by @wilsonng above) a deferred project (or two) where I capture things, about this project, I would like to consider later on. Lets call this projects “Project A Q4” and “Project A Q1”.

@rnbutler87 Thanks for your suggestion. I have been keeping anything not executable in the short term away from OmniFocus for years. In my OmniFocus I keep only projects related with my year’s resolutions. Anything else gets stored in some folder in my drive that I won’t review until end-of year.
What I was talking about was tasks related to on-going projects that were not part of the initial estimation.

#8

That’s an interesting perspective, @lgrassini - how do you see GTD as being at odds with scrum and agile?

Interested to hear, I feel like GTD makes my sprint planning and scrum really effective as I see them as working together really well.

Thanks!

ScottyJ

#9

I realize I asked for your perspective without sharing my own. Haha. Here is my take on how GTD works with scrum and agile:

Since, in GTD, the first steps of workflow are collect/capture, process/clarify, and organize, I see everything as going in to (in agile speak) backlog, as that’s really how GTD works. Only in the review and do phases do commitments really get made (with the exception of date/time-specific commitments made as part of the organize phase).

So for me, sprint planning is effectively the review phase of GTD workflow: what, of all things in backlog, are we going to commit to doing in the next two weeks? And really, even this is just a flavour of GTD weekly review, which is effectively the same thing. So everything committed becomes an available project/task, everything else is deferred, put on hold, or assigned to an on hold context.

Scrum, then, is the do phase: what, based on yesterday, are the tasks I am going to do today, which are no longer relevant, and what needs to be added?

I found that having a basis in GTD made me very ready to work in agile/scrum for this reason. With a weekly review practice at the epicentre of my personal productivity, my life is basically a series of one week sprints. Applying this kind of thinking to my team and our agile project planning seemed very natural.

In stricter agile/scrum language, a lot fo my OmniFocus projects are therefore user stories, and for many, the next action is “Assess this project at sprint planning”. This allows me to support the management of our backlog and the sprint by creating a clear division between what is available and what isn’t.

Hope this helps, but again, really looking forward to understanding other perspectives and where challenges may lie.

ScottyJ

1 Like
#10

Hi mbutler87,

your workflow comes very much down to the approach I am looking for: Using OF only for to manage the concrete next actions/steps for projects and not clutter it with project planning, that might or might not come true.
I looked at your suggestion of nvALT and I really liked the idea. Although, it keeps crashing on my MacBook with High Sierra. Do you have any pointers to make it work for me or to an alternative tool like nvALT? I would like to give it a try.

Best regards,

Ralf

#11

Hi Ralf

I’m glad you found this useful. And I’ve not actually upgraded to High Sierra yet so thanks for the heads up on this.

I found this article online which sounds like it should resolve the nvALT issue for people who have already installed High Sierra.

I’d be interested to know if this resolves the issue for you so do let me know!

#12

Hi,

I read this article before I installed nvALT. But this is the exact version that causes the crashes.

I’ll have to see what I will do with it. I like the concept of searching/creating notes very much.