Re: [scrumdevelopment] Re: Extending a Sprint
- If there is a "good reason" understood and agreed to by all, then it
makes sense. However, forcing it onto the team to meet some arbitrary
deadline (Which releases are - as often as not) is clearly a violation
of the relationship between the team and the business. It is the
business' right to specify what is to be delivered and in what
order-of-priority. It is the team's right to work at a pace that is
livable and sustainable.
On Tue, Jun 30, 2009 at 7:17 AM, jmilunsky<jack@...> wrote:
> This should be a one off type of thing. I agree that it's a slippery slope.
> We did this once in 9 months. So I would avoid it under normal
> But this scenario seemed to me like one in which you could make an allowance
> as it was right at the end of the release cycle or so it seemed.
> But if the release cycle is every couple months then doing this every couple
> months is probably not a good idea.
> --- In firstname.lastname@example.org, "Michael Spayd" <michael@...>
>> My general position is to not extend Sprints, to follow the timebox quite
>> religiously because it drives the wrong team behavior, of "oh if we have
>> just a few more days we can get this other thing done, or we didn't quite
>> get this done, so just give us some more time and . . ." If you don't like
>> those rules, don't do Scrum, do Kanban.
>> For those who suggested extending the length by a few days, or do
>> different Sprint lengths, I have a question:
>> what if you had a team with a few members who asked to do this same thing
>> (extend the Sprint) every second Sprint because they were on a monthly
>> release cycle and this always happened? (I ask because, knowing some inside
>> information about the question posed, this is what in fact has happened).
>> Would you make the same recommendation, or a different one?
>> --- In email@example.com, "banshee858" <cnett858@> wrote:
>> > >
>> > > My suggestion is that you lavishly pay your developers for overtime.
>> > > Buy a case of red bull, keep the pizza delivery company on speed dial,
>> > > provide sleeping bags for the office, and have a turbo session for the
>> > > last
>> > > few days of the sprint. You can get away with 20 hour work days, if
>> > > your
>> > > team is willing.
>> > >
>> > > Make sure they're willing due to incentives.
>> > >
>> > > Just my opinion...
>> > >
>> > I am not sure if this is sarcastic or not. Is that what you really
>> > think?
>> > Carlton
- I strongly recommend against extending a Sprint. This has little to do with forcing anything upon the team and much more to do with getting to DONE and maintaining the value of the Scrum team's time. Bottom line -- when a Sprint ends is an arbitrary point in time at which the team stops, looks at what they completed, and decides what to do next. If the incomplete items are still the most important things to be done, they'll be picked up and finished in the next Sprint.When teams start looking at the end of the Sprint as the end of the coding effort (until, of course, the final Sprint), they begin undesirable behaviors like trying to squish a bunch of work into the last couple days of the Sprint. That's where corners, and quality, gets cuts. Teams needs to work at their highest sustainable pace all the time, and not try to cram at the end. If they complain that they only need another day, the response from the Scrum Master should be, "Fine. You'll get that day right after the next Sprint Planning." No harm, no foul, folks. The end of a Sprint is that and no more -- the end of the Sprint.Jim SchielOwner/CEO, Artisan Software Consulting LLCAgile Coach, CSTOn Jun 30, 2009, at 11:55 PM, Adam Sroka wrote:
- Jim Schiel wrote:
>BTW, I've seen teams do certain stories at the beginning of the sprint,
> I strongly recommend against extending a Sprint. This has little to do
> with forcing anything upon the team and much more to do with getting to
> DONE and maintaining the value of the Scrum team's time. Bottom line --
> when a Sprint ends is an arbitrary point in time at which the team
> stops, looks at what they completed, and decides what to do next. If the
> incomplete items are still the most important things to be done, they'll
> be picked up and finished in the next Sprint.
taking them to done-done to meet a mid-sprint release, and then
continuing with the rest of the stories in the sprint. It causes a
little extra work, but came out pretty well.
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
- On Jul 1, 2009, at 9:47 AM, George Dinwiddie wrote:
> BTW, I've seen teams do certain stories at the beginning of theThis is how I recall handling this while on a Scrum dev team.
> taking them to done-done to meet a mid-sprint release, and then
> continuing with the rest of the stories in the sprint. It causes a
> little extra work, but came out pretty well.
Acceptance criteria included "Deployed/released on x date", where x is
within the Sprint. I don't recall it causing any real problem. This
would allow the Sprint duration to stay constant.
. An example checklist for serious ScrumMasters: http://tinyurl.com/cvdwor
- Hello, Jim. On Wednesday, July 1, 2009, at 11:45:39 AM, you wrote:
> I strongly recommend against extending a Sprint.Per a chat with Chet: I would not at all recommend extending a
Sprint while in the middle of it. I'm much less troubled by saying
"This next Sprint will be N days long because <some external
If another does not intend offense, it is wrong for me to seek it;
if another does indeed intend offense, it is foolish for me to permit it.
-- Kelly Easterley