Titles
In
- Problem to be solved (ex. “Client contact form is allowing lots of spam submissions”)
- Outcome to be achieved (ex. “Client contact form no longer accepts spam submissions”)
In Asana, the task should be titled according to these formats.
Custom Fields
Tasks should follow our standard Workflow for assignment, due dates, etc. Each Asana project must be specifically configured to include the task settings that we need (which is annoying), but we have a standard project templates that allows us to standardize. For Asana specifically, we may use:
Projects
Asana allows you to put tasks into multiple projects. This is super helpful for cases where a single action will affect multiple sites at once – for example, a server upgrade for a server hosting two sites for the same company. It is also helpful because it allows you to create meta-projects like “Ty Priorities” to keep track of specific tasks from various other lists in a unified location.
Dependencies
Tasks which must be complete in order for this task to be actionable. Should be set in advance. Tasks with dependencies should have the status “Blocked” or “Pending Prior Task”.
Hours (Est.)
We have a single Estimate custom field which should contain the expected hours that the work is expected Cantilever to take. Team members should not take on a task without also accepting the estimate as realistic. When someone takes on a task if they do not think the estimate is realistic, they should push back and get it updated. Please note that the estimate is for the company’s effort, not for one person’s part of the task. Estimates on tasks should include anticipated PM, QA, and approval time related to that task.
Importance
The Importance field will have the four options in our
Task Description
The task description should be comprehensive but also clear. It should be written in such a way that a PM (even from another project) could read the task and understand:
- Why it is important
- What the context is
- What the “Definition of Done” is
You can create tasks using our format by using the standard Task templates available when making a new Asana task:
This template is available by clicking the Plus next to a section, or the dropdown next to the “Add Task” button at the top. Unfortunately it isn’t available if you just click Add Task at the bottom of the list.
Since Asana descriptions are just simple text, for larger or more complex tasks it can make sense to instead write “specs” in Notion or Google Drive and link to them in place of the Overview.
Subtasks
Subtasks in Asana are very powerful. They are fully-fledged tasks of their own and can have all custom fields and even their own subtasks! It would be possible for us to create a full “Tree” of project todos based on high-level work packages, and then create granular sub-tasks for each individual action within those work packages. However, sub-tasks are limited in that:
- Subtasks are difficult to move between subtasks list and the parent project (requires manual drag-and-drop of each item)
- Subtasks are not visible from the parent tasks unless using List view for the Project
- They can be confusing in search or My Tasks because they don’t automatically show the context they are from.
- There is no automated relationship between the parent task and sub-task deadlines, so you can push back the parent task date but the sub-tasks stay the same. This means lots of manual work.
Therefore, we don’t use Subtasks for tracking “real” work. Instead we use them as a checklist of the Approvals that need to happen in order for work to go live. Asana has a special kind of task for tracking approvals, which have four states (Pending/Approved/Changes Requested/Rejected) rather than just two (complete/incomplete).
Approvals
Strategists should add approvals during clarification as blank placeholder tasks. This serves as a checklist for the assignee to get those approvals. Placeholder approvals should not be assigned to anyone so they don’t clutter anyone’s My Tasks list prior to them being actionable.
QA is one kind of approval which has specific rules and rituals. Other kinds include code reviews, strategic reviews, and design reviews.
When the task owner is 100% certain that the Definition of Done is satisfied, they should then fill out the approval sub-tasks and assign them to reviewers. For QA, this means providing the information in the QA checklist. The sub-task should be a complete encapsulation of the request, barring context that can be gleaned from the original task.
If the reviewer has no comments they should mark the approval as “Approved”.
If they have comments or bugs to report, they should add their comments as subtasks of the original task (parent task of the approval subtask), not the approval subtask. They should mark the approval sub-task as “Changes Requested”. The approval sub-task should be used lightly instead of being a place where conversation occurs.
Once the responsible party has fixed the issues, they should comment back to seek approval again, and turn the approval status to “Pending Approval” (empty), and the cycle repeats.
Blockers
A “Blocked” task should be shown as blocked by creating the blocker itself as a task, either in the project (within a Blockers section, for example), or as a sub-task to the blocked task. The blocker should then be set as a dependency for the original task. This turns the task icon into the hourglass, which is how everyone will know the task is blocked.
