Critical Path

A colleague of mine recently asked what I meant by "critical path." I gave her the following example, which she suggested I share:

"Critical path" is a project management term. It represents the longest running sequence of tasks required to complete a project. For example, given the following tasks:

• Task A takes 1 hour.
• Task B takes 2 hours.
• Task C takes 30 minutes.
• Task D takes 45 minutes.

If the tasks must be completed in alphabetical order, then the critical path is A-B-C-D. And, the project will be complete in 4.25 hours.

But, if you have a helper, and the tasks only need to start in alphabetical order, then the critical path is A-C-D. And, the project will complete in 2.25 hours.

• Elapsed Time 0:00 - You start task A. Your helper starts task B.
• Elapsed Time 1:00 - You finish task A. You start task C
• Elapsed Time 1:30 - You finish task C. You start task D.
• Elapsed Time 2:00 - Your helper finishes task B.
• Elapsed Time 2:15 - You finish task D.

But, what does an agile software developer need with an antiquated term like critical path? I was using it in the context of removing engineering work from a broader business process that could be completed faster if the other department involved could execute their tasks in parallel with engineering. So, there!