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

3049RE: [scrumdevelopment] RE: What to do with "loose ends"

Expand Messages
  • Karl Scotland
    Mar 12, 2004
      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.
    • Show all 26 messages in this topic