We left off in Part 1 of this article asking the question of HOW Agile and Critical Path could exist side-by-side in a single project schedule without affecting each other (much)? I laid out three dilemmas there are to resolve when you try to combine these two approaches that are different from each other but not each other’s opposites (as I argued in Part 1):

The WBS of an Agile schedule is sprint-oriented (adaptive) with user stories within each sprint, whereas the WBS in a Critical Path schedule (predictive) is broken down in a deliverable-oriented way with activities within each deliverable.
Agilists estimate in anything except hours, whereas predictive folks need the estimates expressed in hours to create their Gantt Charts and calculate Critical Path.
Agilists don’t like identifying all dependencies between activities, but predictive people need all dependencies, the right types of dependencies and all entered correctly into their scheduling application. They need complete and correct network logic.

Let’s dig into the solutions I am proposing now, and remember that I’m suggesting a compromise to make combining BOTH approaches in ONE schedule work.

The benefit for this true hybrid approach of Agile and Critical Path is being able to manage your team using Agile (manage down) while managing your executives using Critical Path (manage up). Another use case is if one part of your project team wants to use Agile (software), whereas the others want to use Critical Path (hardware). This hybrid approach if useful for project managers that find themselves in the following situations:

You are building a hardware product (Critical Path) that has a software component as well (Agile).
You are designing a defense system with tangible components (Critical Path) and software components for intelligence gathering and processing (Agile).
You are building a software application (Agile) for a client that expects a full tally of the cost and a firm target date for delivery as captured in a firm-fixed price contract (Critical Path).
You are a contract research firm that is performing the clinical study for a new vaccine and needs to create the database and software interfaces specific to this research (Agile), as well as accomplish the purchasing, configuring, and distributing of hardware devices across the world to capture the results of the clinical study (Critical Path).

These are just some examples of how you might combine Agile and Critical Path (CP) in one schedule. Let’s solve the dilemmas to make this work.

Solution 1: WBS for CP and Agile

By tagging each line item (activity or user story) in the WBS and using the grouping feature in your scheduling software, you can easily convert one WBS to another. You can do this in Microsoft Project, Primavera, and most other scheduling applications. Let’s take a look at the Critical Path view with a deliverable-oriented WBS (with deliverables, activities and milestones):

Note that each line item (activity) has been tagged in the field Sprints with one of labels Sprint 1 – July, Sprint 2 – August, or Sprint Backlog, which allows me to create the following Agile view using the Group By feature in the same project schedule in Microsoft Project, as shown below with all activities allocated to the sprints and backlog:

Solution 2: Converting Agile Estimates to Hours for CPM

I once faced having to shorten the schedule of an Agile project for a team that was on the Critical Path of a highly visible, business transformation program at a financial institution. They were managing the data migration from an old system into a new one and presented a schedule that was half a year long. A similar endeavor had taken only three months ten years earlier. It was clear that the executive would not tolerate extending the duration of the program unnecessarily. I offered the option of taking on more team members, but the Agile team did not want a larger team, because that was not ‘Agile’ enough. I reacted in an ‘agile’ way to this ‘Agile’ team’s objection by proposing the start of a second Agile team working side by side with the first. The second team would take half of their workload and shorten their project by roughly half, but they did not want this either … until some executives overrode their objections. ‘Agile’ dictates that you keep the team size constant so that team members get to know each other and learn each other’s strengths and weaknesses. Agile empowers teams by having them self-assign all activities, which can optimize the allocation of assignments and results in a constant stream of productivity (called ‘velocity’ in Agile).

Clearly, the dilemma of reconciling different types of estimates is tougher to resolve, but here is the solution I eventually found that is based on keeping a team size fixed. Let’s say that your Agile team consists of a fixed number of people—ten. You have an Agile project with sprints of one month each. Each month is about 4 weeks of 40 hours/week or 160 hours per team member. So, you have 10 team members * 160 hours per month resulting in 1600 hours per month.

Let’s assume that the Agile team accepted a total of 800 points into their first sprint of one month long. We know that each point converts into two hours of effort (=1600 hours / 800 points), and we can now convert Agile estimates into hours of effort. We can create a Gantt Chart and have Microsoft Project calculate the Critical Path (provided I have entered the dependencies). You can see this in the previous illustration where each Agile estimate in the column Agile Points is converted using a custom-built formula (using a conversion factor of 3.87 for this particular project). You see the results of this calculation in the column Hours (Agile Pts. * 3.87) that was created using one of the extra number fields (like Number1, etc.) and the customize fields feature accessible from the ribbon (Format, button Custom Fields to enter a Formula).

Finally, these calculated effort estimates are copied for this sprint from the formula field and manually pasted into the out-of-the-box Work field while either:

Keeping the task Type to Fixed Durations (and Effort Driven is No) if you want to see how many team members need to be allocated to each activity, or
Keeping the task Type to Fixed Units (and Effort Driven is No) if you have assigned the resources already and want to see the durations calculated by Microsoft Project. In this case, you may need to make some tweaks to the durations (if they extend beyond the fixed duration of the sprint).

You’ll now have a schedule that started with Agile estimates, but also has the estimates in hours—person hours in the field Work and business hours in the field Duration. You need the Durations to build the Critical Path schedule a.k.a. a Gantt Chart.

The velocity for a team with a constant number of members typically stays constant over time (across the sprints), and the number of points accepted into each sprint will also stay relatively constant after the third sprint when the proper velocity has been established for that team. The conversion factor can be adjusted after the first few sprints, if needed, because the resulting hours need to be copied into the Work column on a sprint-by-sprint basis. So, for each sprint you can determine a new conversion factor and adjust the formula. In most Agile projects, you don’t need to adjust the formula any longer once the velocity has stabilized after the second or third sprint.

No Solution 3: Compromise Needed

As the project manager addressing the question ‘to link or not to link,’ I simply request that the Agile team works with me and helps me sort out the dependencies between the activities (or user stories) in the sprints and in the entire backlog. I create a complete and correct network logic for all WBS-items, and this has, so far, been a reasonable compromise for all Agile teams to make. At least for the ones, I have met so far.

With these three dilemmas addressed, organizations can make both approaches co-exist in ONE schedule, which allows one to happily switch from an Agile view of the schedule (when presenting to my Agile team i.e. managing-down) to a predictive view of the schedule (when I present to executives i.e. managing-up or managing‑out to clients). Switching views takes two clicks of the mouse, and in short, I manage‑down with adaptive Agile and manage‑up with predictive Critical Path.

I also manage-in and relax by keeping a handle on the overview and avoid the stress of a difficult situation where different stakeholders pull me into different directions: i.e. my team wants to be managed in an Agile way, whereas executives that pay my salary, want forecasts.

If you would like to learn more about how to convert an Agile schedule to a Critical Path schedule or vice versa, please refer to my textbook ‘Forecasting Programs’ (see this website: Books – ProjectPro Corp). Chapter 3 is entirely dedicated to this topic. To explore the Microsoft Project schedule from which I created the screenshots in this article, download the ZIP-file and Microsoft Project schedule from our website at Articles – ProjectPro Corp.

Thanks for reading both parts of this article Part 1 here if you missed it).

Please leave any comments you have below. I have made some daring statements and have summarized the last 30 years in the way I see them. I look forward to hearing what you agree and disagree with in this series of articles.