Usage guide

What makes a good task?

A good task includes:

A necessary and sufficient definition of what needs to be done (the "definition of done"). How detailed this needs to be is subject to the negotiation between the customer and the performer - the performer should only agree if the task is sufficiently clearly defined that they know how to decompose it into sub-tasks themselves, and if they are confident that they can complete all required sub-tasks before the agreed-upon deadline.
Links to all relevant resources (always prefer linking to copying data - DRY).

Used consistently, this system should be less dependent on fixed planning cadences than our current cycle system because (a) tasks always exist that can be picked up and (b) renegotiation explicitly triggers re-planning. Still, specific repeated cadences will probably be helpful - I propose a "strategic planning cadence" every 6 weeks and a "tactical planning cadence" every 2 weeks.

Strategic planning

Every 6 weeks, the chief customer (project lead) and relevant parties meet to define and plan top-level tasks for the next 6 week strategic cycle. This should result in at least 6 weeks of planned work (and possibly more unplanned to-dos for the future).

Strategic planning proceeds "right-to-left" on the task DAG:

First, the chief customer defines the top-level task(s). (these may also relate to planning cycles longer than 6 weeks).
Second, the chief customer and relevant parties plan those tasks following the procedure above, until the period, the team, and the task(s) have been decomposed into:
1. Three sub-periods of two weeks each
2. Sub-teams
3. Sub-tasks, each of which is assigned to one of the sub-teams as performer, and whose deadlines should generally fall on the sub-period boundaries. This may involve sub-planning within the sub-teams. At the end, when all customers and performers consent, this task graph becomes the work plan for the next 6-week period.

Tactical planning

Every 2 weeks, the chief customer (project lead) and relevant parties meet to check in on progress relative to the strategic planning cycle top-level tasks and plan / re-plan tasks for the next 2 week tactical cycle. Typically, these tasks should have already been planned, and this can just be a quick check-in - but it's also a good opportunity to check that progress is on track w.r.t. the strategic goals, and reconsider / re-plan if other factors have changed.

Tactical planning proceeds both left-to-right and right-to-left. Considering what tasks have been completed, the chief customer and sub-team leads may decide to re-plan, rearrange, or re-scope remaining tasks within the 6-week period (but should generally not change high level tasks agreed upon during the last strategic planning cycle).

Synchrony & asynchrony

Roughly, the organization operates in two modes:

Synchronous - e.g. when you're on a video/audio call or meeting in person, and can receive immediate feedback
Asynchronous - otherwise, when you can't receive immediate feedback

Any promises made that will not be completed while both the customer and performer are in a synchronous session should be tracked by this system. For example:

If you are asking a teammate to pair review your code on a call, and you will finish the review on the call, this does not need to be tracked.
If you are asking a teammate to review your code, and you give them an intro on the call but expect them to finish later, this does need to be tracked.

In general, anything that you agree to do is a task. If there isn't a task, don't agree to it.

Granularity of time tracking

The goal of this system is to provide high estimation accuracy for planning across the organisation. In order to do this, we need estimated time vs actual time taken to be tracked when relevant. This is most important with larger tasks that take on the order of days, it's not so important with small stuff - if a 20 minute task takes 40 minutes, that's not a big risk to organisational prediction accuracy, but if a 2 week task takes 6 weeks, that is. As a reasonable rule of thumb, say:

Tasks that you expect to take 1 day or more should come with a time estimate, and
When you complete a task with a time estimate, you should note how much time it actually took

Self-reference

This system can reference itself, e.g. "Plan task XYZ" is also a task.