To Subtask or not to Subtask

English Forum Use Cases
21

The problem I have with assigning a subtask to a project is that it then clutters the project with too many similar tasks. I am using Asana in a similar way as @Craig_Fifer - as a production calendar. I, too am using it the way Asana recommends, which is to make the entire calendar one project, each content item a task, and each steps to create the content a subtask. Our sections are used as overall stages of the task (piece of content).

My thought has been to assign the overall task to the next person who has responsibility for the next subtask. This helps in the short term, but doesn’t help in long term planning on a calendar. Any other suggested workarounds?

An option on the calendar to view subtasks or not may be helpful to many.

22

Great point. There should be an option to auto assign the sub-tasks by way of check box (or something similar). Moreover, a way to highlight all and assign to one person (if not assigned already) would be a huge help (if there isn’t an option already and I just missed it).

7 Likes
23

Love that people are having this conversation. I kept thinking that I was just using subtasks incorrectly and was missing some sort of functionality that wasn’t there. I’ve always loved the idea of keeping my projects clean, and thus dove straight into subtasks when I started using Asana. Unfortunately, I learned the hard way that sections are currently necessary for the current design of the tool. Perhaps it’s the ADHD or the way I like to quickly process through my tasks, but until it’s VERY visually obvious that subtasks are present and nested under a task, I’m afraid they are all to often missed or forgotten about in our workflow.

13 Likes
24

Lots of dialogue on this including a request to be able to expand and collapse Sections within a Project.

16 Likes
25

We used to use subtasks in our projects, but it became a big mess. So now we use sections quite heavily and it’s so much clearer and easier to manage.

I personally hate subtasks, and only use them if all of the information is contained in the subtask title. Going into a subtask to read descriptions and comments, and download files, is very painful and easy to miss.

For example, if the parent task was “Design website home page” then the subtasks could be, “Header”, “Footer”, “Main content”, etc. No further detail needed.

Even then, why bother when a section can be used?

26

Maybe it’s me, but the reasoning behind having the home page example be it’s own task vs a section is for feedback. It depends on how many people are weighing in on each task, but I don’t see how breaking it down by header, footer, main mockup, is very conducive to feedback.

I run into this issue a lot - my role spans managing design, video production, events, etc. and it can sometimes become confusing if you break it down into tasks like that, whereas if I have a ‘Mockup Home Page’ task, then I create the small ‘milestone’ subtasks if needed (like, creative brief, etc.) - then the actual feedback back and forth is done on the main task.

If we used sections (and trust me I use them liberally in my projects, I think it would be confusing to casual users as to where to add their feedback. For instance, I’m looking at the header task, and I think about how it needs to also reflect the footer - well now I sent feedback for something that’s not the footer task, etc. and it could get confusing if multiple people are doing it, unless you have very strict plans - so if feedback or comments overlap tasks, copy them to both, etc.

I don’t know, maybe these are problems that have different solutions, but it’s why I find subtasks useful despite the drawbacks.

I do agree on a lot of the other points made here about them though.

2 Likes
27

I’ve never actually used the example I provided (we don’t break things down that way). I was just trying to illustrate how it could be used. In reality, we use a section and then tasks under that section. No confusion and it’s all easily accessed, nothing is hidden from view, it appears in the team schedule, etc. I literally don’t have a single drawback from doing it that way.

28

Oh yeah I know that’s not the best example, but my issues run through similarly. I find myself always having to balance logic in Asana with the reality of our use-cases, and feedback/discussion clarity is a big one.

1 Like
29

We use Asana primarily as an editorial calendar, so each task represents a content item (e.g. news release or video) and the sections are the months of the year. The subtasks are the steps to produce each content item (e.g. get the facts, public social media), which basically would be tasks if each content item were its own project.

If we used sections to group the steps, our list would be thousands of lines long at any given time, and all the steps would appear on the Calendar view.

My takeaway here is that each level of hierarchy in Asana can represent different real-life items, and you have to choose the right setup for your situation. I appreciate having the flexibility that many other platforms don’t provide.

9 Likes
30

Yep, no arguments here. I was just talking about our own usage. But like I said in my first comment, I find it quite difficult to navigate through the details within subtasks (descriptions, attachments, comments).

I think tasks could be easily improved by adding icons which indicate:

  • If there is a description.
  • Number of subtasks.
  • Number of attachments.
  • Number of comments (including unread comments).

And this would apply to subtasks as well, so that when you’re in a task and you see a list of subtasks, you know what to look for.

12 Likes
31

I think that’s the biggest thing that would help - improve the UX of subtask icons/notifications.

Such as is referenced here:

12 Likes
32

This is a good list!. I would also add from my work with the CSV to PDF CSV To Asana Simple List Generator- My Gift To Community - #21 by James_Carl that Asana please have subtasks automatically add the Project of its parent task. The idea of subtasks floating around as unattached to a project causes not only problems for the free report I had written for the community but a general problem on many many uses and searches.

7 Likes
33

We’re relatively new to Asana as a team, but we’ve embraced it and use it to manage a PD development and delivery schedule. We are working through the use of subtasks and sections. We actually do both. One of the reasons we use subtasks is to eliminate scrolling for tasks with many subtasks. I second (third?) the recommendation to be able to collapse/expand sections.

Also, having to assign each subtask (and sub-subtask) to a project to make it appear on the calendar means that we don’t use the calendar view as much. It’s not worth the extra time to us to have to do that manually.

We too, have set the expectation that all comments and conversations take place on the main task. People leave their progress updates after each working session as well. It’s helping the “higher-ups” stay up-to-date in way that they weren’t able to before.

Overall, we really love Asana (OK, maybe I love Asana more than anyone else in my company at the moment), but it’s helping us to stay organized and on-track. Also, SO.MANY.FEWER.EMAILS. All of the things Asana is designed to do.

1 Like
34

Love your enthusiasm, @Erin_Hommeland!

35

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:

  1. 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.
  1. 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.
  2. 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 :wink: D.S.

Cheers and thanks for this great thread/discussion. //Michael

9 Likes
36

I would upvote the heck out of this suggestion.

37

Subtasks work beautifully on Trello board cards. I had high hopes for the same in Asana once they launched boards but was left disappointed. A sub task on a card is often assigned to a different person than the owner of the parent task. The limitation in Asana is that the card face only shows the owner of the parent task. Please Asana, show ALL assignees on the card face to make triaging of work across teams more efficient.

5 Likes
38

Hi @Stephanie_Connolly you can add the Sub Task to the board by adding the Parent Project to the sub task using tab+p then adding the parent project.
Hope that helps.

Jason.

39

I’m a project manager at an ad agency, introducing Asana to my team… and subtasks has definitely been the most confusing thing. However, I do find them necessary for certain aspects of our work.

Specifically, when we are routing items for review through different people, we use subtasks. The parent task of “internal review” is assigned to the PM, and all the information & background about the piece being reviewed is set up in that parent task’s description. Then the routing to copy, art, proofreading, etc, is done as subtasks.

By clicking on the parent task, everyone can see the status of the route, and the PM maintains responsibility for making sure it’s completed.

There are definitely pros/cons to subtasks, but I think a few tweaks would improve them greatly:

First, I would like to see an indication in the project list view that a task has subtasks. Even better, would be a toggle to show those subtasks indented and below parent – as is done in the print view.

Second, I would like to be able to add the project’s custom fields to subtasks. I don’t really understand why this isn’t part of the functionality right now – it really hobbles the usefulness of custom fields for us.

Third, the UI should be improved for showing the relationship between subtask and its parent. Not as critical, because over time we’ve just learned where the parent task link is, but for new users it’s very confusing, especially when landing on a task directly from an email or a My Tasks link.

Great discussion – I hope to see more here.

6 Likes
40

Thanks for the response @Jason_Woods. My comment here re: subtasks may have have been unclear, so let me try again.

In the context of managing an Asana Board project, each card on the board represents a parent task. Let’s say that I have a parent task assigned to Person A, then subtasks on that parent task that are assigned to Person B and C. The issue is that the card face on the Board shows ONLY Person A as an assignee. This is misleading and hard to manage, particularly when you have multiple parent task cards with multiple subtasks across a team of 3 or more on the same Board. All cards “appear” to have only 1 assignee, when in fact, there are multiple assignees.

Trello shows ALL assignees on the card face to facilitate triaging at a glance. Otherwise, with Asana, you have to drill into each card to get a holistic view of ALL assignees involved. I’m hopeful Asana will rectify this because I feel their recently released Board project view is far more useful than task lists. But this particular issue is a real limitation for my organization.

3 Likes