39433Re: [scrumdevelopment] Extending a Sprint
- Jun 29, 2009Hello, Tobias. On Tuesday, June 30, 2009, at 1:06:45 AM, you
> Indeed. The stringent time-boxing requirement of Scrum is thereYes, and ...
> for a reason. It surfaces organizational impediments and
> dysfunction. Extending a sprint when things don't align will simply bury the problem again.
> If you extend a sprint once it is likely you'll do so again. And
> again. And you'll continually fail to use the opportunities
> presented to you to improve the way you work. Don't take this one
> to the team, just stick with the framework. It's simpler.
Sprints used to BE a month.
Having sprints of 14 days then 17, then 14 then 14,
then 14 then 17, then 14 then 16, then 14 then 17, i.e. filling
out the month each time,
doesn't seem to me to be breaking the timebox in the sense of
And ... if this team is so good that they don't need a stabilization
kind of Sprint, and can actually do a few stories DONE DONE in the
extra couple of days, maybe there isn't a big problem.
And ... if the team's velocity is stable, stretching the iteration
won't really do anything but bring a couple of stories forward one
release, once, which isn't going to impact total value delivered
much at all.
And ... if their quality is that good, why not just release at (or
two days after) the end of every Sprint, instead of on a monthly
And ... I'd like to visit them and see if they're really that good.
It could be that this is a sensible extension of a really good team
that for some good reasons really needs or wants a one-month release
cycle and a short Sprint. Or it could be a more average team just
messing around while there's some really interesting impediment
waiting to be removed that would make them go twice as fast as they
Just because XP doesn't talk about how to make fire, should we assume it
requires us to use sticks? -- Richard MacDonald
- << Previous post in topic Next post in topic >>