As a user of Asana at my company (with my team), I find it frustrating to understand how to properly use the tool not only for forward-looking communications (what needs to be done) but also backward-looking retrospective (what has been done, how did we perform). The resolve to this frustration has been by my thinking about this took as a record-keeping/data-entry tool. Specifically, we enter tasks that need to be done, and complete them recording some information about the work. Rarely is the work isolated to one task, so this has lead me to the realization that tasks must be coupled by relationships whether a concept of “sub-task” or “dependencies”. The relationship is the record keeping part that allows for use to see some aggregate of tasks describing the effort of a single feature or unit of work. I’ll describe what I find are the pros/cons of these existing features (sub-tasks/dependencies) and what could potentially resolve the issues.
Sub-Tasks: What’s nice about the relationship defined by a sub-task is a “grouping” organization and hierarchical structure. It’s not clear whether sub-tasks are tasks that are blocking the completion of the parent task, or whether they’re smaller steps or units of the parent task. Visually, sub-tasks are great because they really are prominent that they are related to the parent task both in the task details view and a task list view (a project or My Tasks). Additionally, a task can only have one parent, which means it must not be separate work that may be required for two separate tasks. For this, it appears the dependencies feature shines.
Dependencies: Dependencies create a task graph relationship that is very flexible. This is great because a task have have two or more parents (can block more than one task). This makes it far more useful then sub-tasks. The main con with dependencies is the interface: you cannot create tasks from this section (the task must already exist), and you cannot see these relationships in the task list views aided by a drop-down UI (project/My Task). These short-comings make the feature a bit clunky.
Solution:
-
Joined Task Relationship: We can join together the two features of sub-tasks and dependencies. This new feature could be called “Blockers” or something. It would be a list where you can easily create a new tasks by writing one out or choose an existing task to add to this list. A tasks can be a blocker for multiple tasks (just like dependencies), and all blockers can be shown in lists views just like sub-tasks. Any tasks that has blockers cannot be complete until the blockers are complete. In summary, we elevate sub-tasks as a feature to be a graph relationship like dependencies (and we can therefore remove dependencies). The feature name could be called “blockers”, “downstream” or simply “related”.
-
Task Actions: Allow for the ability to define “task actions”, simple buttons that will do some pre-defined mutation to a tasks such as: change a field, add a task, etc. These act as many functions or scripts that can be played within the context of a particular task. A example use-case would be to “Submit Results for Review” which could create a templated “Review” task as a blocker to the current task. The task action could be a single button without any parameters, or it can prompt the user for input in a modal/window that includes a form of defined fields needed for the action to complete (input the link to the pull-request or link to work needing review, input the assignee for the review task, etc). These task actions are a powerful way to program workflows for a team and allow them to define what workflows are needed for various kinds of work that tasks represent.