On traditional, sequential process an important part of the project manager’s job is identifying the project’s critical path. The critical path is the sequence of activities that will take the longest to complete and that, therefore, determines the overall length of the project. For example, suppose that my wife and I want to see a movie this afternoon. Before we can go to the movie she has three errands to run that combined will take her 90 minutes. I only have two errands but mine will take 120 minutes. In considering start times for our film, we better plan on one starting at least 120 minutes from now because my tasks will take that long. My sequence of errands are the critical path for our project of getting to the theater in time for the film.
A common agile project management question is “where is the critical path” on agile projects?
Because agile projects are split into a sequence of iterations this question must be answered two ways:
- What is the critical path within an iteration?
- What is the critical path within a project?
When I first started doing Scrum projects I worried quite a bit about the critical path. I had learned that this was part of my job as a manager. When I would look with my team at a set of tasks we had committed to for an iteration I had a tremendous fear that only I–the all-knowing project manager–would see the critical path. That without me to point it out to the team we would have one day left in each iteration, have perhaps 42 working hours available spread across our 7-person team, have only 38 hours of work remaining. But those 38 hours would all need to be done sequentially. I foolishly lived with the irrational fear that the team wouldn’t see this.
As I look back, I’ll admit to not getting over this fear as quickly as I think I should have. It probably took me two years of always worrying that this would be the time that the critical path would sneak up on the team and they wouldn’t see it. But after those two years I eventually came to the not-very-insightful but extremely eye-opening realization that the team would always be smarter than me. During those two years (and in the ensuing nine) I have yet to work on an iteration where we neared the end and realized that we mathematically had the capacity to do the remaining work yet couldn’t because of sequential dependencies inherent in the remaining work.
My conclusion from this is that the critical path within an iteration:
- is easy to see because the iterations are so short (typically two to four weeks)
- does need to be considered by the team but this can be very informal and usually without even using words like “critical path.” It happens naturally during a team’s iteration planning meetings and daily standups when they ask themselves questions about how they’re going to finish the planned work
Because of these points, my view is not to worry about the critical path within an iteration. Team members will naturally figure it out in the iterations where it’s important.
As for the critical path of an entire project, this is sometimes worth considering. In my Agile Estimating and Planning book, I wrote about rolling lookahead planning, which is one way for a team to deal with elements of critical path planning. Rolling lookahead planning involves teams (on projects with multiple teams) conclude their iteration planning meetings by taking a five minute look ahead at the next 1-3 iterations. This high-level forecast of which features will be added next can help identify dependencies between teams. This is often enough to avoid being surprised by a long critical path.
On a very complex project I wouldn’t be opposed to even drawing a network diagram to see the relationships among the next 3-6 months worth of features (ideally written as user stories). However, before I spent time doing that I would really try first to write mostly independent product backlog items. If a project’s product backlog items are independent and can be developed in any sequence then critical path issues disappear.
Trackback from http://dotmad.blogspot.com/2007/03/critical-path-in-scrum.html
Adi–It may indeed be the case that it will be necessary to use MS Project to identify some dependencies; however, it shouldn’t be the ScrumMaster who does this. The team is responsible for figuring out how they’ll do the work. This principle of self-organization is key to how agile teams perform so well. The team should figure this out rather than rely on the ScrumMaster. And I still contend that in most cases the critical path will be easy for a team to find without a tool. In 12 years of running Scrum projects I’ve never seen a team need a Gantt or PERT chart to figure out the critical path within a single sprint. (It’s been occasionally necessary across a release plan but never one sprint.)
One issue we’ve been struggling with is trying to identify the dependencies among stories in the sprint. On paper, the set of stories we have committed to look great, but in reality, there are dependencies that sometimes cause our tasks to be blocked and our stories end up being way off our original estimates.
Is it “wrong” to use something like an informal Gantt chart during sprint planning to help us to “see” what the dependencies and timing requirements are and what would need to be done at a higher priority in order for our stories to be able to get to “done” by the end of the sprint?
Our purpose isn’t to plan out the sprint, but rather to make the dependencies and timing requirements visible. Would you still discourage us from doing this? Does it give it a different spin if we called it a “feasibility” chart? Or a dependency chart?
Hi Sandra-
If you and the team think it will help then I’d suggest giving it a try. I’d keep it pretty lightweight and use it mostly for discussion along the lines of “OK, if we finish this by Thursday (let me put a mark here on the whiteboard) that let’s us start the other on Friday and that means we just have to do such-and-such before the end of the iteration next Thursday…” I suspect if you try that a few times you’ll find that drawing it was useful as a way of providing context to your discussion but that the discussion, not the chart, was the value.
However, I’m going to play psychic for a moment and guess that you have fairly long iterations (3-4 weeks) and probably have some large product backlog items. If so, there may be two other options that will work better for you:
–considering smaller product backlog items
–considering shorter iterations
I am working on a new project that entails agile software development. Are there any examples that discuss how scrum correlates to an Earned Value System ?(EVMS)
Hi Kirk–
Tamara Sulaiman has written a good article on “Agile Earned Value Metrics” that is on the Agile Journal website. You can see it at http://tinyurl.com/2ruhzw (which expands into a big URL).
Mike, The article Tamara has written adresses many of my questions.
Thank you.
Hi Mike,
In this posting, you refer to a network diagram. Are you using that term to refer to a classical CCPM Project Network or rather a more loosely defined relationship diagram inter-relating features?
Thanks,
m
A more loosely drawn one. I don’t want to ever get too caught up in thinking that each of my estimates is accurate so it’s just an informal layout showing a likely sequence of the features to be built. It sometimes helps find dependencies.