Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Critical Path at Sprint level? and/or Release level?

Expand Messages
  • Paul Hodgetts
    ... Some good answers so far -- some other thoughts... As someone mentioned, at the release level the notion of a critical path doesn t really apply. At the
    Message 1 of 4 , Nov 26, 2005
    • 0 Attachment
      Zzz wrote:

      > Is it possible to identify the Critical Path at the Sprint
      > leve? and/or at the Release level?
      > Any help would really help me here ...

      Some good answers so far -- some other thoughts...

      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
      cross-training measures)?

      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
      -----
      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.
    Your message has been successfully submitted and would be delivered to recipients shortly.