Re: [scrumdevelopment] Critical Path at Sprint level? and/or Release level?
- Zzz wrote:
> Is it possible to identify the Critical Path at the SprintSome good answers so far -- some other thoughts...
> leve? and/or at the Release level?
> Any help would really help me here ...
As someone mentioned, at the release level the notion of a
critical path doesn't really apply. At the release level, we
aren't looking at specific activities, we minimize
dependencies as much as possible, and we don't break things
down to the level of assigning any sort of work to anyone.
So the components that make up typical critical path planning
are not part of agile release planning.
Instead, at the release level we represent units of work in
terms of deliverables (features), not the how (tasks). These
are prioritized, so in a sense the critical path is from
highest to lowest priority, but again in different terms.
At the sprint level, most teams will discuss where they see
potential risks and dependencies, and they will take note of
those things to help in deciding what to get started on first,
and what to keep an eye on during the sprint. But there's a
recognition that we won't know enough for the fine-grained
decisions until we have some feedback from how the sprint is
really playing out. So the critical path is not so much a
plan as a heads up as they get started.
During a sprint, day-by-day, the team is certainly paying
attention to the immediate critical path over the next few
days. They adapt their understanding of it as they work on
their tasks and synchronize in their daily scrums.
I often hear teams (actually mostly project managers) express
concern and disbelief that things will be missed and horror
will ensue if we don't sufficiently plan for the critical
path at the start of a sprint. If the team is working just
fairly well together, and takes advantage of their chances
to collaborate and adapt, I haven't seen much horror ensue.
They can usually spot the risky stuff pretty quickly, with
enough time to adapt to the occasional surprise.
What really hurts, though, is an obsession I see with teams
wanting to load up every drop of their available task hours
for a sprint. With no time to spare, planning the critical
path seems a necessity. But it rarely plays out -- the team
almost always has to adjust either schedule or scope anyway.
A Scrum team should allow some buffer (slack) in their
capacity to give themselves room to adapt. From what I've
seen, the resulting productivity from adaptation with some
slack time seems to beat the resource optimization approach.
Specialization can also play havoc with sprints. When the
team becomes more and more constrained by who can do specific
tasks, they have to start worrying more about whether that
person can handle the work, and they're less able to adapt as
the sprint plays out. Even a little flexibility so that the
easier tasks can be dynamically assigned can make a big
difference. For very specialized teams, I often find that
the team has to pay more attention to critical paths. I hate
it, but I'm not sure what else to do (other than immediate
Another thing to be careful of is that in planning out the
critical path (and the resultant dependencies and often task
assignments), the team may get locked into that plan. They
then tend to focus on the plan more than on the adaptation
and collaboration that makes a Scrum team effective. As some
famous someone said, it's not the plan that's important, it's
the planning. Scrum teams plan all the time.
Hope that helps,
Paul Hodgetts -- CEO, Coach, Trainer, Consultant
Agile Logic -- www.agilelogic.com
Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
Complete solutions for adopting agile processes, Scrum and XP.