- On dealing with overcommittment, I was reminded by Jim Coplien
recently in Sweden that the pattern "Yesterday's Weather" deals with
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
> 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.