The Zenoss dev team uses Rally for project management. It's fine for planning the activities of the entire team, but as a personal task manager I find it pretty useless. Its interface is unwieldy, and it doesn't allow for more or less fine-grained tasks. Great to get a high-level view of an iteration; bad for any low-level organization.

Since I like OmniFocus for my own task management, I've developed a system that mirrors Rally at the highest level, but allows for much more versatility at a lower level (not, of course, restricted to Rally; should function perfectly well for any Agile project). OmniFocus and Rally sync up surprisingly well, as far as that goes, but OmniFocus lets me take those extra steps to get myself an actual task list for the day and switch priorities on an hourly basis.

First, the basic translations:

Agile Concept	OmniFocus Analogue
Iteration	Project Folder
User Story	Project
Task	Action
Estimate	Estimate

Now, the details. I've organized my project folders at the top level according to my various roles; under "Zenoss Developer" I have two folders, Current Iteration and Backlog. Since I don't use OmniFocus for project planning, just for task management in the foreseeable future (which usually doesn't include next iteration), there's no need to have folders for every iteration in the release.

When I break a project down, I put the resulting projects and tasks under the Backlog folder, in subfolders according to feature ("User Interface," etc.). I also have a single-action list called Tickets into which go actions representing tickets I need to fix. I try to include time estimates where appropriate.

After we finish our iteration planning, I modify the projects in the Backlog folder with any changes, then I drag those projects and tickets planned for the iteration into the Current Iteration folder. I then break down tasks into sub-tasks for the nitty-gritty stuff that's too small for Rally but for which I still want a reminder.

When I create a project based on a user story, I use a template prepopulated with the tasks associated with every user story—code review, running unit tests, communication with QA, etc. To this I add the tasks unique to the particular project. This cuts down on the drudgery of data entry while ensuring I don't forget anything. Contexts are all preset as well.

Now my iteration is easy to see (and manage) at a glance. I have a "Current Iteration" context focused on the project folder, so I'm not distracted or overwhelmed by the entire project at once. When priorities shift, I can change the order of the projects within the Current Iteration folder, or move things in and out of the Backlog folder.

When the iteration nears its end, I've already begun to do some of the planning needed for the next iteration simply by virtue of using OmniFocus in a way compatible with Rally. Anything left in Current Iteration gets split to the next iteration, and whatever's at the top of Backlog gets dragged into Current Iteration to fill in.

I don't worry too much about time estimates in OmniFocus, although I do make some attempt to populate the field just for the sake of keeping the information at hand. But generally I leave the reconciliation of my velocity with tasks to iteration planning in Rally.

Anyway, this little system works pretty well for me. While at a high level it mirrors Rally, I also get the benefits of sub-tasks and user story templates, as well as integration with non-Zenoss-related actions.

How do you reconcile your Agile project with personal task management? I'd love to hear your methods in the comments, OmniFocus or no.

Read More...

A standing opinion about Evernote is that it's fantastic at accepting information but terrible at giving it up again. You can search from within the app, but any kind of integration with other apps is only barely possible—by, say, linking to the Evernote web client.

OmniFocus, for its part, is exceptional at helping you organize your life, but really isn't designed to be a repository of detailed information, so integration with Evernote is a natural desire. For example, I have an OmniFocus single-action list which I use to store blog post ideas; it's a natural next step to have an Evernote note associated with each containing notes and drafts.

So here's the method (admittedly, somewhat manual) that I've been using to keep references to Evernote notes with associated OmniFocus actions.

Read More...

I live in OmniFocus most of the day. I have lots of perspectives set up to help me parse my various responsibilities (see my previous post, "How I Use OmniFocus," for more details); in particular, I have one perspective called "Global Tasks" (View Mode: Context, Filter: Active, Grouping: Ungrouped, Sorting: Due, Action Filter: Next Action) that essentially gives me a list, ordered by dueness, of what I should be doing right now.

It helps me focus to have that list of tasks constantly in front of my eyes. This is counterbalanced by my desire to save screen real estate for the assorted terminal windows and browsers I need up to do my job; OmniFocus takes up valuable real estate. So I set about writing a quick script to pull tasks from OmniFocus, format them, and return them as plain text, which I could embed on my desktop with GeekTool.

set taskList to ""
tell application "OmniFocus"
    tell the default document to tell the front document window
        set perspective name to "Global Tasks"
        set oTrees to trees of content
        set n to count of oTrees
        repeat with i from 1 to n
            set oTask to value of (item i of oTrees)
            set taskTitle to name of oTask
            set projTitle to name of containing project of oTask
            set taskList to taskList & taskTitle & 
                "  (" & projTitle & ")\n"
        end repeat
    end tell
end tell
return taskList

I saved that as ~/src/omnifocus_tasks.scpt and added a Command item to GeekTool that ran osascript /Users/ian/src/omnifocus_tasks.scpt every minute. The result was exactly what I wanted:



Now, even if I hide OmniFocus to make room for something else, I can't forget to check for my next tasks and keep everything up to date.

Read More...

OmniFocus is a first-rate task manager. It's so flexible and powerful, however, that coming up with a workflow and a set of contexts that efficiently aid the management of one's tasks can be difficult. I've fiddled with my setup for several months, completely overhauling my contexts three times--should they be time-based (Today/Tomorrow/Soon/Next Week), resource-based (Laptop/Grocery store/Printer), state-based (Home/Work/Errands/Spare time)? I've tried out several perspectives, seeing which fit into my workflow and which are disruptive or merely unhelpful. And I've experimented with the various levels of containment--folders, projects, action groups--in order to determine where they mesh with the natural hierarchy of my own tasks.

Most helpfully, I've perused the OmniFocus forums, hoping to glean insight from the practices of other users. While much of that time was spent navigating around outbursts from orthodox GTDists, I managed to find and appropriate several ideas. In an effort to ease others' OmniFocus learning curve, here's how I have things set up.

Contexts

My first act upon installing OF was to set up a large, complete hierarchy of contexts describing many aspects of my life. It didn't take me long to realize this in no way helped me. My difficulty lay in not having a clear idea of the identity of contexts in general. Nearly everything for which I need OmniFocus involves my job, which is basically a single large context, as I'm a programmer on one project on which I work from home. Having a single context seemed like a misuse to me, but artificial distinctions between contexts was equally ridiculous. For example, there's no reason to have a "Laptop:Photoshop" context, since there's no situation in which I'll have my laptop but /not/ Photoshop.

Eventually I decided to drop all my contexts and allowed them to be created when needed, to try to figure out the contexts in which I naturally think of tasks. This led to a pretty good set -- only a few, but each had real meaning. They ended up describing a mix of states and resources:

• Errands
  
  • Grocery Store
  
  
  • Home Depot
  
  
  • ...


• Exercise


• Computer
  
  
  • Blog
  
  
  • Zenoss
  
  
  • Internet
  
  
  • Printer


• People
  
  
  • Gillian
  
  
  • Jason
  
  
  • ...


• Home


• Waiting
  
  
  • Code Review
  
  
  • Chad
  
  
  • Gillian
  
  
  • ...


• Spare Time

These are fairly run-of-the-mill, except the "Waiting" context. I set the status of that context to "On Hold", which means that when I apply it to an action, the project is similarly on hold. It took me some time to realize that I could change the context of an action as it moved through various states; there's no need to create actions, for example, like "Send email about X", "Read response about X," and "Apply response to X", merely to use the contexts "Email", "Waiting" and "Computer"--instead, just have "X" as a task, and change its context to match the state it's in. But don't go overboard; use as few contexts as necessary. I generally just move things in and out of "Waiting" as needed, which lets me know if I can work on it at the moment or not.

Due Dates

Due dates are apparently Not Used in GTD unless a task actually has a hard date by which it must be completed. I shied away from them for that reason, attempting to use contexts, flags, then folders to indicate relative priority of tasks. Eventually I gave that up, since it seemed silly to ignore a perfectly good mechanism for recording when I planned to work on a task merely because of its connotation. Now I use due dates to indicate the time I intend to have finished a project or action; this allows me to set up perspectives sorted by due date. The thing at the top of the list is what I work on next. If priorities shift, I alter due dates accordingly.


Perspectives

Note: I've left off Duration and Flag filters from these perspectives, because I don't currently have a use for them; all perspectives use the default.

Work
View Mode: Planning
Focus: Work
Filter: Remaining
Grouping: Due
Sorting: Due
Action Filter: Available

My projects for work, grouped by due date, showing available actions only--thus, if a project is stalled by the "Waiting" context, its actions won't be visible (though the project will). Answers the question: "What will I be working on today/tomorrow/this week?"

Now
View Mode: Context
Focus: Work
Filter: Active
Grouping: Ungrouped
Sorting: Due
Action Filter: Next Action

A flat list of available next actions, sorted by due date. Answers the question: "What should I do next?"

Completed
View Mode: Context
Focus: Work
Filter: All Contexts
Grouping: Completed
Sorting: Project
Action Filter: Completed

Actions I've completed, grouped by completion date. Answers the question: "What did I do yesterday/this week/last week?"

Waiting
View Mode: Context
Focus: Work
Filter: On Hold
Grouping: Context
Sorting: Due
Action Filter: Remaining

Projects on which I'm stuck because I'm waiting for something from someone. Answers the question, "What's blocking me from finishing my tasks?"

Errands
View Mode: Context
Focus: No Focus
Filter: Remaining
Grouping: Context
Sorting: Project
Action Filter: Available

My errands, grouped by context; this gives me a nice list of what I need from each store.

During our morning standup meeting, I reference "Completed" for what I did yesterday, "Work" for what I plan to do today, and "Waiting" for what's blocking me. Then when I start work, I live in the "Now" perspective. Weekends I'll reference "Errands" (and a "Spare Time" perspective I have yet to perfect).

Template Projects

This is one I got from the forums. If you have a project with several actions that occurs every so often, but not at regular times, make yourself a template project that you can duplicate. For example, I have a "Travel to Austin" template that reminds me to pack a toothbrush, make hotel reservations, fill out an expense report, etc.; when it's time to make a new trip, I duplicate the project and set the due dates accordingly.

Another great use of this technique I found on the forums was for grocery shopping. Create template projects for recipes with actions for all the ingredients. When you plan your meals for the week, make copies of the appropriate recipes, and your "Errands : Grocery Store" context will have a grocery list all ready. Sync to your iPhone and go.

Set the start date of the template project far in the future and put it in a folder at the bottom of your projects tree, so it doesn't get in the way of your active projects. You can apply the appropriate contexts to the actions, because they'll all be pending.

---

Hopefully, these examples will help newcomers over the hump presented by the very, very large blank sheet of paper OmniFocus provides. As my OF configuration has evolved, I've found myself using it more frequently. When you manage to the find the groove, you'll never leave.

Read More...

A significant amount of my work comprises resolution of bug tickets, for the tracking of which Zenoss uses Trac. Since each of these usually corresponds to a single action in OmniFocus, I've been looking for an easy way to send a Trac ticket directly there (keeping a reference to the ticket in the notes field) other than typing it in manually, which is what I've been doing for months. Today I found it!First, I installed the OmniFocus URI Handler, which ingeniously parses URLs using the "x-omnifocus:" URI into OF actions. Since you can use OmniFocus's mail processing rules (e.g., "Do Something :: MyProject @ MyContext #Due // Note"), you can enter any kind of action you want by assembling the appropriate URL.

Once I installed this (trivial, just your basic .app dragged into /Applications), the rest was obvious. Here's the bookmarklet appropriate for my needs, with line breaks so it's readable:

javascript:<br />window.location="<br /> x-omnifocus://parsetasks?text=" +<br /> encodeURIComponent(document.title) +<br /> ":: Tickets @ Zenoss " +<br /> "#" + prompt("When is it due?") +<br /> "//" + encodeURIComponent(location.href);<br />

In my case, "Tickets" is the name of the single actions project into which I dump these, and "Zenoss" is the component I apply to them. I'm prompted for the due date (in a very non-GTD fashion, I use due dates as a rough way to manage priorities, in the absence of other mechanism), which, thanks to OF's acceptance of sensible expresions of time, I can enter like "3/3/2009" or "next thursday 5:30am". Finally, the ticket URL is put in the notes field.

Obviously, you'd want to customize the bookmarklet to suit your project and context, but this should provide you with a simple example. Here's the bookmarklet I use myself:

Trac > OmniFocus

Of course, this bookmarklet is generic enough that it'd work for any web page at all; it's just the title of the page and the URL.

Creative uses, anyone?

Read More...