Problem

Task management is how you decide when and what to work on—in life, business, projects. In compsci terms this is a priority queue. But unlike a textbook priority queue, the dimensions and measurements are unspecified, amorphous, and dynamic. And the cost of failure is high:

The most pernicious and subtle bugs are from mismatched assumptions made by authors of various components. — Fred Brooks, MMM

For many this is like diet fads: try lots of hopeless methodologies, give up, repeat. “I need to rank EVERYTHING” is not a tractable framing if new tasks arrive every week (day? minute?). Yet many task-tracking tools have features to “help” you (globally!) rank items.

The naïve, generalized, intractable model of task management is:

Task management: an N-dimensional classification problem with unknown features and incompatible units.

But it is a solved problem if you frame it in a tractable way.

Solution

The solution is to remorselessly truncate the N-dimensional, unit-less problem into a 1-dimensional, fixed-cost problem.

Prioritizing a snapshot

Prioritizing once is relatively easy. Expressed as the “Warren Buffett method”:

Only the top three priorities matter, ignore everything else (until you finish one).

“Three” is adjustable, but more than ten is not useful: the main point is that there is a fixed number of Most Important Things that everyone on your team knows each morning are the Most Important Things.

Prioritizing a stream

It is less obvious how to apply that method it to an ever-growing queue of work. Prioritizing a snapshot in time is easy—but new information is arriving continuously, uncomfortably, and this is where you give up, or pray to scrum, or hire a project manager to outsource the question and delay the truth. Evaluating your backlog every week (or whatever your scrum master is dreaming of), is a waste of time. Your backlog-grooming meetings are a waste of time multiplied by the number of people in the meeting.

The Eisenhower Method hints at how you can comfortably apply Warren Buffett to a stream, by using a crude rubric: decide urgency and importance for each new item, so that it falls into one of four buckets:

  1. Important and Urgent? Do it.
  2. Important but not Urgent? Schedule it.
  3. Urgent but Unimportant? Delegate it.
  4. Unimportant and Not Urgent? Drop it.

Almost nothing should land in bucket 1. Most new items go directly to bucket 2; “schedule it” means “unceremoniously pitch it into the amorphous blackhole called your backlog”.

The crudeness of the rubric is critical: it must be cheap. Its distraction cost per item must be near-zero. New items flow on-demand through this triage function.

Consultation

The idea is to maintain fire and motion at low cost, on-demand (no meetings).

The intake queue for your project, business, life is an infinite stream. You can fight the stream at high cost with scrum, “planning poker” meetings, elaborate Jira features, hiring more PMs, and various other coping methods for buying randomization disguised as optimism—then wait some months for the mediocre results and kinda ignore the lack of ROI…

…or you can accept that randomization is inevitable, embrace it, and use that power to comfortably just drop things. If your current capacity is full, drop whatever exceeds it. This is how any healthy system works, it’s called backpressure.

This planning and intake-handling scales because each team (~10 people) does the same process. You only have cognitive capacity to reason about the topics in your personal scope (your team, project, etc.). You can peek at the “top three” priorities of another team, but it’s not something you think about day to day.

Implementation

For a team project, your goals are:

  • Utilization:
    • Discover work by writing down tasks.
    • Schedule high-priority/high-leverage work.
  • Visibility: people can see progress on projects and epics.
    • Roadmap
    • Communicate with stakeholders (%done, green/yellow/red)
    • What we did we do? What was delayed?
  • Forecasting: predict what we will do.
  • Availability: no un-triaged items.

Funnel

To organize a team of human AIs, you need to be able to draw from a pool of triaged tasks. This is solved with a very simple mechanisms: shallow trees.

The general model of your triage “funnel” is:

Funnel = streams + projects

“Sprints” are your team’s “unit of work”, typically a two week block of time used as a planning target. The sprint is a stream that absorbs new items.

“Projects” (also “Epics” at a higher hierarchical layer) are shallow trees that group items. With this simple structure, whenever you have capacity to move to the next project, you just draw from the top N subtasks of that project. (The top N subtasks are again prioritized in the same “Top N” manner, where we don’t care about anything not in the Top N.)

By applying Warren Buffett on-demand, you funnel work into (1) the current sprint, (2) anything tracked as a project, (3) labelled items in your backlog.

Just as you know your current “top three” topics for the next week or month, you also have a rough idea of the “top ten” topics for the next year(s). Each topic is one of the following:

  • project: a shallow tree of subtasks under a finite, deliverable topic, or
  • epic: a shallow tree of ideas or projects under a (potentially never-ending) topic.
  • label: any arbitrary topic attached to any item.

Triage

A task is triaged if it has a topic. That means it was either labeled and snoozed to the backlog (unstructured), or it was added to a project as a subtask (structured). Whenever an idea or request arrives, anyone can “triage” that item, which means do one of the following:

  • add it as a subtask to one of the “top ten” projects, or
  • put it in the backlog (add labels or tags too, if you like)

This is how you translate an infinite stream into structures, at fixed cost. New items attach to known topics. Everything else goes into the backlog—with topic labels, so you can reach them in the future when you decide that topic is now one of your top three priorities.

To plan and forecast (because your manager or director wants this), you need to estimate the subtasks of a project. The main thing to remember here is that a task can be small, medium, or big—“days”, “weeks”, or “months”—and attempting to estimate with more granularity is a waste of time.

Project

Projects have structure: ordering, dependencies.

Just as the global scope of your “top three priorities” ignores the rest of the infinite stream, when you are looking at the flat list of subtasks in a project, you also only care about the top ten items there. You are not re-evaluating all of the potential tasks every time you consider the project. Only the top ten tasks matter. If something comes to your attention and it’s more important than one of those top ten items, then put it near the top of the items. The other items shift lower.

The priority of an item is decided by its leverage. If an item blocked by an external factor, that also shifts it down (because the cost increases, which decreases leverage).

leverage = (impact / cost)

When your team needs more work, or you’re planning the next two weeks, you know the top three highest-priority projects. Pick one. Then assign items from the top ten subtasks in that project to your team. Repeat.

Sizing

“Scrum” people try nonsense like t-shirt sizing or Fibonacci sizing. Such logarithmic units are incompatible, so you can’t easily calculate a meaningful total, which means you can’t compare groups of tasks by cost. Can’t mention the sizes in an email without extra explanation. Etc.

To size a task, think in terms of days of work. A small task takes one day. It doesn’t matter if it actually takes only minutes or hours because the variance washes out over a large pool of tasks. Medium tasks take, say, three days. Large tasks take eleven days. Anything bigger is a project, not a task: size its tasks, don’t size the project. But if you don’t know the tasks yet, just size it at one-hundred eleven days.

  • small = 1 day
  • medium = 3 days
  • big = 11 days
  • project = 111 days

Scalability

If one person can’t manage your backlog, then your team has too much scope. There are two ways to deal with that:

  1. Let the excess items go un-triaged (and focus on your top three priorities).
  2. Create another team to subdivide the intake queue. Now you have two teams, each with their own “top three” priorities.

Business card

  • Task tracker = social media for collaborating on projects (passive coordination). Passive (habits) >> Active (meetings).
  • Sprint = planning unit-of-work. Whatever you are working on for the next two weeks.
  • Planning meeting = edit the upcoming sprint.
  • Project = a task with subtasks, a (shallow) tree.
  • Epic = an ongoing topic, a task with projects, a (less shallow) tree.
  • Backlog = “out of scope until we finish the current top three priorities”.

Project management

Project management is the art of glancing human behavior. Cross-team coordination. The Ben Franklin effect. Relationships. Roommates. Meetings are the work, and Work Is Work.

Task management is a subset of project management. There’s no simple answer, but open source development suggests that passive mechanisms are where to look. “Bug bounties” and advocacy are active, and thus don’t scale.