That's true, and I can see why you avoid them. Last time I touched Jira, I quickly learned that subtasks are annoying.

Dependency releationships between tasks are more general and better overall. Unfortunately,

> Hierarchical data structures are not the easiest to deal with and come with a litany of edge cases. It can also be quite overwhelming UX wise.

Don't know of any software that fully figured it out. Even MS Project, which does the relationship and scheduling parts a-ok, is a PITA to use in general, and has some pretty annoying bugs that made me stop using it. Being able to irrecoverably brick the auto-scheduler and have it suddenly crash on opening the project file is a kind of show-stopper.

Another tricky challenge here is scope. Planning, scheduling and doing are three different mindsets, and it's tough to balance them all in a single tool. Someone who figures out how to do it well stands to make a lot of money.

Planning and scheduling/prioritizing are two distinct processes people often confuse. Planning is about identifying what needs to be done, and breaking it down into a network of tasks joined by dependencies. Scheduling is figuring out who's going to do what and when they're going to do it.

Planning is figuring out your service needs e-mail verification, password reset, and some transactional messages, to stuff like "design e-mail templates" "write templates for {verification, reset, account confirmation} e-mails", "set up infra for sending e-mails", "add {verification, reset} URL flows", "make it send {verification, reset, confirmation} e-mail on {{relevant action}}", etc. Scheduling is me assigning "design e-mail templates" to Joe in graphics dept. and giving him 3 days for it, assigning you the "set up infra" task and giving you a week, and knowing the "make it send ..." tasks won't start until next sprint, at which point we'll find someone to do them, etc.

In naive Agile reality, while <<whatever lands in the "we can't do that until we do other thing" doesn't even get scheduled>>, it gets recorded somewhere (e.g. product backlog), but it won't have its dependency relationship encoded. So every sprint, someone goes over a heap of such tasks, and has to manually reconstruct those relationships, to the degree it lets them plan out the next sprint or two. This both adds work and limits the ability to plan forward (you ain't going to be even thinking about stuff that's obviously beyond the horizon).

While it's true that stakeholder priorities change (as they should), and this affects scheduling, it affects planning much less, as the dependencies aren't about order in time, they're about order in execution. Dependencies aren't volatile - no matter what the stakeholders think this week, you won't be able to work on "make it send emails" until you can send e-mails (infra task) and have e-mails to send (design/write) and have them be useful (endpoints/routes for links). This is useful information to have encoded, particularly with more interdependent features - not only the system will help you do the scheduling correctly, it'll also let you quickly tell that unscheduling work on X now will delay work on Y down the line, etc.