Story Point – a revolution in task estimation? Part 3: Critical Path

What a critical path is, and what is it used for?

Critical path is an issue that is often ignored when discussing estimation in story points. Perhaps, it results from separate roles of Project Manager and Scrum Master and, consequently, different duties and views on a project.

The critical path method, which is a method used to estimate the minimum project duration and determine the amount of scheduling flexibility on the logical network paths within the schedule model. This is it as for the theory. In practice, it is an arrangement of tasks in the order they can be performed. It is created to identify which tasks cause extending the project end date (that is what blocks us) and what are their relationships. Thanks to this we can learn whether specific actions must be performed one after another or whether they can be performed independently, and how long can we suspend a given action so that it does not delay the final task delivery date.

This means that setting a project critical path helps to estimate the project costs and duration. It gives us knowledge of how long the project should take and how to allocate people so as to avoid downtime. In short, it is a very useful tool in the hands of any person responsible for the project outcome — not only the one planning the budget or contacting the customer, but also the one taking care of performance.

Please find below the critical path diagram (with sensitive data deleted) created by me for one of my projects.

Image – Critical Path

In the case above, I created the critical path using the method described in PMBOK. This does not mean that it is more or less correct than others, e.g., the Gantt chart criticized by the agile development practitioners. It enables to easily load information on task completion deadlines and specific actions leading to the goal. Such an approach gives a false feeling of safety as if everything was planned and considered, and all we need to do is just act. It stiffens a project and makes us unable to respond to changes as in the case of a normal product backlog.

This is a dangerous approach. In order to avoid substituting a project backlog with a Gantt chart, I choose the method suggested in PMBOK. A critical path presented in this way perfectly illustrates relationships between tasks, and at the same time is not associated with a project scope list — this is the goal I want to achieve using a critical path. Moreover, a path arranged in this way does not need to be very precise since this is what the backlog is for. In this case, we need general relationships and actions whose length is determined by the project completion.

Why do I need a critical path in an agile project?

It seems that a well-planned and well-prioritized product backlog eliminates the need for a critical path since it takes into account relationships between individual tasks. While defining and reviewing requirements, e.g., backlog refinement, the Product Owner and development team identify relationships between individual requirements/user stories and set priorities for them. The development team communicates to the Product Owner the relationships that he/she might not be aware of, e.g., due to technical reasons. This is reflected in the contents and arrangement of requirements in the product backlog.

Moreover, one of the guidelines for defining good project requirements (e.g., in the form of user stories) is to ensure that they are independent which means that a single requirement should cover a useful whole. Having this in mind, we can identify requirements so that they form an independent system element, if possible.

But does it mean that we don’t need a critical path? I think not because a critical path supplements a scope not substitutes it.

In this case, the critical path answers the questions which do not stem directly from even the best backlog, such as:

• shortening of which task will accelerate value delivery?
• which tasks can be performed independently?
• will a delay in performing a given task affect the others?

Answers to these questions enable us to manage a project better. If any action significantly delays the others, it’s good to divide it into parts or assign it to more people. Then, the value of this action is not that big, and it can be postponed in order to deliver a smaller package of requirements earlier. As you can see, a critical path helps to provide one of the key values of the Agile approach, which is the fast delivery of ready-to-go solutions.

How to create a critical path without using time estimates?

In the case of story points, we cannot create a traditional critical path. For many people, it is a huge inconvenience that undermines the reasons for abandoning time estimates.

Fortunately, the lack of time estimate does not mean that we cannot prepare a critical path for a project. User stories can also be mapped onto a relationship diagram on the basis of the order of their creation and the size estimated in the form of story points. Abandoning man-days will help to get away from assigning dates subconsciously, creating fixed obligations or assuming a scope as finally closed. So if we replace time with a story point, we will still know the assumed (yes, assumed since it can be changed at any moment) order of actions. However, it would be general enough not to put the team under pressure and to determine where the scope can be adjusted to deliver value earlier.

Another method of using a critical path in an agile project is the one suggested by Mike Cohn and called “rolling lookahead planning.” According to this method, each plan is made for a few (3–4) iterations ahead to identify all possible relationships and order of performed actions. Such planning takes place at a higher level than Sprint planning, but it is precise enough to enable you to foresee relationships between user stories.

To recap, if you learn how to treat critical path as a tool for visualizing relationships, not as an agenda, it will bring planned benefits, and using story points does not make it less reasonable or useful. Critical path is just one of many project tools, and the decision to use it should be deliberate. In practice, it may often happen that the amount of work spent on creating and maintaining a critical path exceeds its benefits.