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 about 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 be complete in about 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!