Respect the time box, and do "just-in-time planning." Don't do so much up-front decomposition, and rely instead on iterative delivery to provide you with an emergent design.
From an agile planning viewpoint, you're doing something fundamentally wrong if your backlog requires complex dependency graphing. In particular, you're either:
- not leveraging the concept of thin, vertical slices of functionality to deliver incrementally; or
- you're trying to do too much decomposition up front.
Agile frameworks aren't designed for work that requires heavy up-front design and specification. They're meant for incremental, iterative, and emergent designs. Leverage that. You must embrace incremental, iterative delivery and emergent design if you want to be successful with an agile methodology.
If you're the project manager, you need to refine your methodology. Specifically, you should rework your product backlog so that you aren't trying to do so much up-front decomposition that your entire backlog is filled with tasks.
Ideally, your backlog will be filled with cohesive epics and themes, with only work for the next few iterations decomposed into relatively independent user stories. The user stories should follow the INVEST mnemonic, so that you don't have a complex dependency graph to deal with.
You should only be defining tasks for the current iteration. While tasks can certainly have dependencies, a feature that has been properly scoped for a single iteration should not have so many tasks that a complex dependency graph is necessary.
Sometimes, you may need a time-boxed story spike to help refine, decompose, or plan the work ahead, but that work is not expected to fit into the current iteration! If you uncover new or unplanned tasks during an iteration, schedule the work for a future iteration whenever possible. Otherwise, you may need to halt the current iteration and replan. That's how iterative methodologies fundamentally work!
There are lots of methodologies for dependency graphing. One of the more useful ones in the software development space is the Mikado Method. It helps the team or developer work backwards from the goal to the current state, identifying dependencies and refactorings through a directed graph. Ultimately, though, the graph is a means to an end, and not a goal in itself.
If you aren't doing software, other techniques may help you resolve dependencies and order your graph. Entire books are filled with the theory and practice of how to generate such graphs, so an exhaustive list would be out of scope.
In agile methodologies, though, the work scheduled for the iteration rarely needs the level of graphing you seem to be asking for. While it's very useful for defining the critical path on refactorings, unscheduled work is too high-level to create such a graph, while scheduled work should be too obvious to need one.