-
Type:
Suggestion
-
Resolution: Unresolved
-
Component/s: Plans - Timeline
-
11
-
5
User Story: "As a product owner, I need to analyze what the critical path of stories is in my release, so I can more closely track/manage whether we are on schedule or slipping"
Background: Jira has the ability to use links to define relationships between stories. One of those relationship types is the blocks relationship (Blocks, is blocked by). If these links are properly filled out for stories, then a release could be visualized as a Tree structure (or series of trees) where the blocking relationship between Stories is shown (blocking relationship between Epics as in Roadmaps are of little value). The stories that Block other stories but are not blocked themself are root nodes of the release trees. You would then recursively traverse the stories blocked by the root, and its' children, and its' children's children (etc) to build the tree graph.
What is Critical Path:
- In general, the critical path is the longest walk in a given story tree (i.e., it has the most amounts of stories that block each other)
- A slang term for this is "the long pole in the tent" of the release
Why is Critical Path Important?:
- Assuming each story is properly sized to fit in a sprint, and best case scenario where you don't start a sprint where one ticket blocks another, you immediately have a rough estimate on the number of sprints needed
- If there are 8 stories in the critical path, ideal # of sprints is 8 to complete the release
- The critical path is the highest risk to meeting any schedule for a release, so it allows you to properly identify, track, and manage the development risk of a release
- If any story on the critical path doesn't get completed in a sprint, your release likely has released a schedule slip of a sprint if you don't find a way to get the critical path back on schedule
How to determine the Critical Path:
There should be two ways to determine the critical path in a story tree in a Release:
- Unweighted - all stories are weighted the same, so the critical path is simply the longest walk (distance) from the root to a leaf in the tree
- Weighted by Story Points - use the Story points estimates to weigh the edges in the tree
- Using an example below, the path that has the highest weight in this example really is the riskier development path; however, the PO should be aware of both of these situations, and be able to use Jira tools to quickly identify these
- 10 stories that all blocks each other but are just 1 story point each
- 10 point weighted distance
- 10 point unweighted distance
- 5 story that all block each other but are 5 story points each
- 25 point weighted distance
- 5 point unweighted distance
- 10 stories that all blocks each other but are just 1 story point each
- Using an example below, the path that has the highest weight in this example really is the riskier development path; however, the PO should be aware of both of these situations, and be able to use Jira tools to quickly identify these
How to display the Critical Path:
As mentioned, it is possible to have multiple story trees in a release, so that would need to be handled
Visually:
- Each story tree should be able to be shown individually, or as a whole in the release
- Story trees should be a proper tree structure, where the Story Ticket # is the label on each tree node
- For a given child node, the child's level should be determined as:(Max of all it's blocking parents) plus one
- As you toggle between the weighted and unweighted visualization options, the critical path(s) should be shown highlighted (I recommend red relationship edges)
Textually:
Although a little harder to ascertain the information, the critical path for a tree can also be viewed as simply a table list of the stories in the walk. So, the root story would be the first one, then its child on the critical path is the second story in the table, and so on.
Jira feature notes:
The current concept in Roadmaps where dependancies are analyzed at an Epic level really are not of value for a development team that has more than 3 developers. An Epic is just a theme of stories that can be organized by the PO in a way that makes sense for the development team to find the stories they are working on. In a given release you may only have a few Epics, but 100 stories - tracking the dependancies of stories is where the value is
The Dependancies report also does not provide the information in a manner that digests what somebody needs to get out of it.