3215RE: [scrumdevelopment] RE: What to do with "loose ends"
- Apr 1, 2004
My experience is that if you reduce the workload, people gold-plate the work or slow the rate to meet the deadline. Consider increasing the quality of the software through increasing the detail of the requirements provided. You end up with the same number of features but each feature has more breadth.
Just a thought :)
From: Karl Scotland [mailto:karl.scotland@...]
Sent: Saturday, 13 March 2004 4:13 AM
Subject: RE: [scrumdevelopment] RE: What to do with "loose ends"
Comments embedded below...
> -----Original Message-----
> From: PaulOldfield1@...
> (responding to Karl)
> >> Has anybody measured what happens if the team commits to
> >> less during a sprint? There was a hypothesis that it might
> >> lengthen the "decompression" time at the beginning of the
> >> sprint and shorten the rush at the end. This would hypothetically
> >> give better quality software owing to more time to think about it,
> >> but you still get the rush at the end of the sprint. If
> you're in a
> >> rush all the time, OTOH, then committing to less should help.
> > I've not got any scientific measurements, but I can report that we
> > consciously decided to plan with a reduced velocity, with the
> > intention that it would result in increased quality. The perception
> > so far is that it has succedded.
> > The other thing we have focussed on to minimise loose ends is
> > acceptance testing (we're XPing aswell as Scrumming if you
> > hadn't guessed!). This has reduced the number of false
> > assumptions which the developers make about the finer
> > details of the expected behaviour.
> Thanks, Karl; useful iformation. IIRC from your presentations,
> your interactive TV sounded like it was always 'in a rush' and
> your iterations were probably short enough not to have much
> if any 'decompression time' at the beginning. If this latter is
> the case (would you concur?) then I agree, "committing to less
> should help".
In some senses it is always a rush because we are doing full releases at
least every month. On the other hand, we have managed the rush by
reducing the amount of work we commit to. The "decompression" happens
at the start of every release, so the amount of decompression depends on
the length of release. A very short release allows for less
decompression. What I found interesting (and satisfying) was that it
was the business team that suggested we commit to less in order to
improve the quality, because the impact of committing to too much was so
> I find it interesting that people can have a 'decompression time'
> at the start of an iteration even when they *know* that they
> always end up leaving loose ends in the rush at the end. I just
> don't know what lessons to learn from this observation (yet).
> Perhaps better feedback on estimation so the loose ends get
> included would help?
I've found that the burn down indicates when the decompression is
decompressing too much.
BBCi at http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
- << Previous post in topic Next post in topic >>