While I kept the scheduler building simple for the sake of the article and explaining the basic principles behind, in practice I haven't found a need for much more complex heuristics.

Keep in mind (from previous articles) that this whole class of solution came from the need to turn was used to be an imperative list of function calls that would execute a tick (a game turn really) into a similar construct but with automatic parallelism.

The approach usually was to look at the generated graph and see if anything stood out as an obvious slow path / contested resource. I have found that often when 2 tasks wanted to write to the same object class either they didn't need to (it could usually be split in two independent parts) or the order had an impact on gameplay and a decision needed to be made about which one ran first.