Hi, I’m a newbe to Asana @Todd_Cavanaugh 's reflection may be especially relevant.
Note: I personally do like sub-tasks. It fit’s my thought-processes very well, but I also have experience from the chaos excessive use of sub-tasks can lead to from other tools. The issue is not tool-specific i.e., some just handle it less badly.
Here are some reflections in favour of using Asana sub-tasks, even if they don’t inherit anything from the paren (which I’ve come to regard as a good thing b.t.w.).
- Divide and conquer
- Task may grow larger that originally thought
- Great way or organising / structuring
- Sub-tasks can be assigned to other’s (also true for tasks, but…)
- But paren-task can be used to group that overall-issue and make it easier for sub-teams to regard only information that’s relevant to the overall issue (the paren task i.e.).
- Not inheriting project-belongings is something I actually now appreciate. At least in “board” projects. This makes the board less clobbered.
- If one want’s visibility for sub-tasks, project’s can be multi-selected and multi-assigned (I do agree with @Brian_Kurkjian - there should be some sort of behavioural setting for this).
- Defining work and structure is IMO far more important than categorisation, at least initially in a project when there’s a lot to do and making order from chaos is in grave need. Time is a factor here. The faster structure emerges, the better.
In case one realises ones sub-tasking frenzy has gone too far, I believe one can merge tasks i Asana (I’ve not tried this yet however).
My favourite reason for sub-tasking in Asana:
Asana has this great ability to make parent tasks into projects AND have the tasks (or more sub-tasks) belong to either, neither or both. This is a really nice feature which I’ve come to appreciate a lot. Because:
- Sometimes tasks just grow. By having sub-tasks, the 1:st level sub-tasks will automatically be converted to root-tasks in the new project, and (one of) their project belongings will be the new project. I.e. new root-tasks will inherit the parent’s project property.
- Sometimes a task/sub-task just don’t “belong” for one reason or the other (this seldom occurs in well defined tasks, but is quite common during project start-up), but you only find-out/realise this later and/or you realise that a task is really a project. Either because:
- It’s to big
- A task/sub-tasks turns out to be/become a never-ending story, i.e rather a processes as opposed to the originating project which might have a clear goal and a clear time-frame.
- A task’s time-frame and goal turns out to be different from the project (or unrelated to it), i.e. not a process but yet clearly different in scope nevertheless.
- You want clearer/different team-definition
- You want different privacy settings
If you convert, then having sub-tasks is an advantage. Additionally, not having the 1:st level tasks belonging to the original project (default behaviour) will save you the (perhaps minor) effort of cleaning these belongings up.
I haven’t used sections yet (it’s only my 3:rd day with Asana), but I can’t see how these would aid build-up of structure and I think converting tasks to project would not work at all as smoothly. I certainly don’t mind using sections (if they can be used for table project - not come that far yet…) as they should aid in over-viewing all the tasks/sub-tasks anyway. I.m. just saying that sub-tasking have great value and that Asana actually handles them well.
I don’t see an exclusive-or for either of the approachs, except possibly for the more advanced API features/abilities mentioned.
Reflections / thoughts
I guess what I was originally most hung-up about is this: "Subtasks don’t automatically inherit the assignee, due dates, tags, or some other information of the parent task".
I however figured: someone must have given this behaviour a real thought. I agree with the behaviour for all but for project belonging. But as mentioned, I’ve come to appreciate the behaviour and have come to realise work-arounds that will do what I want fairly effortlessly.
My first trial project is already 7 task-levels deep, which is a clear case of risking being borderline chaotic. But I’ve found some extremely valuable tricks for not loosing track of issues:
- A task can be a sub-task of one parent-task in one project yet belong to another project than the parent (or both… or more). My first thought was Whut!?. But it’s really great. Those kind of issues are both naturally occurring in my organisation (“needs to be done” issues, but no-one cares enough because they all fall in-between projects - typical issues would be maintenance type of work but there can also be other types much more important)
- This ability can alternatively also used to emphasise another/alternative visibility/overview. I.e. using Asana projects not as projects, but just as placeholders.
- Tasks should belong somewhere or they will easily be lost. To find and operate on them I’ve found the filter “Tasks I’ve Created” combined with multiselect + multioperation very useful so far.
- As several already mentioned, always at least bind/assign to someone/something (if not made project-bound from start). That will make the (sub-)task less prone of loosing. But if you accidentally do (which happens to me a lot when brain-storming): see the bullet above and tidy-up afterwards.
P.S. I will try to be less sub-task and task-depth obsessive. Point is taken D.S.
Cheers and thanks for this great thread/discussion. //Michael