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

Yesterday's weather

Expand Messages
  • Jeff Sutherland
    On dealing with overcommittment, I was reminded by Jim Coplien recently in Sweden that the pattern Yesterday s Weather deals with it nicely. Yesterday s
    Message 1 of 1 , Dec 1, 2006
      On dealing with overcommittment, I was reminded by Jim Coplien
      recently in Sweden that the pattern "Yesterday's Weather" deals with
      it nicely.

      Yesterday's Weather. The velocity of the next iteration is exactly the
      work successfully completed in the previous one. Of course this
      assumes that the time and personnel are fixed.

      The team should never commit to more for this iteration than they
      completed in the last iteration. To get the privilege of committing to
      more, they must finish an iteration early and draw down more product

      The very reasons many object to this pattern are, counterintuitively,
      exactly the best reasons to implement it. There are great companies I
      know who are forever late because they won't execute this pattern
      which will force them to fix a broken Scrum implementation that
      generates ever escalating technical debt reducing velocity gradually
      but ultimately to zero.

      Yesterday's weather is a great way to break out of the "Early
      retirement" syndrome.

      Jeff Sutherland

      > 11. Dealing With Overcommitment
      > Posted by: "Jeff Heinen" jheinen@... vercinget_xx
      > Date: Fri Dec 1, 2006 8:20 am ((PST))
      > As a scrum master, how do you deal with chronic overcommitment and the
      > resulting sprint failures? For example, when a team is routinely
      > committing to 60 story points worth of work, but has a demonstrated
      > velocity of around 30 for several sprints, I've been coaching scrum
      > masters that this is a signal to step in and not allow it to continue.
      > The scrum master should limit the committed work based on established
      > velocity, and coach the PO on how to effectively prioritize the backlog
      > and adjust the scope in order to get their date. I've found that teams
      > seem to become more productive when they first establish a pattern of
      > success and really understand what it means to be done. Then they seem
      > to steadily increase their productivity, building on previous success
      > until they reach a steady state of high productivity that's
      > significantly higher than when they started. I'd rather have a team
      > undercommit and get done early, and then pull in more backlog, rather
      > than always ending a sprint with stuff not done.
    Your message has been successfully submitted and would be delivered to recipients shortly.