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

RE: What to do with "loose ends"

Expand Messages
  • Greg
    I want to thank everyone for your great responses to this topic. I ve been working with Dennis on introducing Scrum into our organization and we have been
    Message 1 of 26 , Mar 10, 2004
      I want to thank everyone for your great responses to
      this topic. I've been working with Dennis on
      introducing Scrum into our organization and we have
      been very pleased with the results thus far.

      Before Dennis posted the question on "loose ends" we
      thought that it might come down to a simple question
      of priority and I guess that it stills does to an
      extent. But, one thing that I'm concerned about is
      that many of these issues are "rough edges" in (or on)
      the product. Individually, they can be easily
      overlooked and are of no consequence. However,
      collectively, these rough edges add up to a product
      that may be perceived as being unfinished or
      unrefined.

      So, if the "loose ends" are considered as individual
      items and prioritized as such they may never be
      addressed. Thus it would seem that this is when the
      collective nature of these "loose ends" is a problem.
      The end result being the product that is unrefined,
      unpolished and ready for prime time.

      Any thoughts?

      I think Charlie Trainor has a good point about quality
      and how those rough edges should be caught prior to
      the review. We obviously have some "opportunities"
      for improvement there.:) But, in the rush to meet the
      goals of the current sprint, how do you balance the
      quality issues (that create many of the loose ends)?


      I also liked Michael Hirsch's approach to bundling
      related ones into a single requirement. That may take
      care of a portion of your loose ends. But, what of
      the ones that don't bundle well? In a complex product
      that list may be significant.

      Has anyone just saved these up for a final (move to
      production) sprint and tried to resolve as many of
      these as can be done during that sprint? Or is that
      asking for trouble?

      Thanks again for all of your advice.

      Greg


      __________________________________
      Do you Yahoo!?
      Yahoo! Search - Find what you�re looking for faster
      http://search.yahoo.com
    • Mike Cohn
      Greg-- A final move to production sprint can be dangerous. But, I ve used stabilization sprints successfully with new teams for years. The idea behind
      Message 2 of 26 , Mar 10, 2004
        Greg--
        A final "move to production" sprint can be dangerous. But, I've used
        "stabilization sprints" successfully with new teams for years. The idea
        behind these was that during sprints we targeted "friendly first use" as our
        quality goal. At any time a sprint's product increment could be given to a
        beta site, put on a private-view part of the website, or whatever was
        appropriate. During the "stabilization sprint" we took quality from Friendly
        First Use to Production Ready. This should mean as little as possible but
        often was polishing like making sure manuals were ready and in-sync with
        the deliverables, etc. Don't become too reliant on stabilization sprints but
        use them as short iterations to polish a release for big-time use.

        Additionally--Yes, collect your loose ends into a story and just call it
        "tie up some loose ends" or "Fix the low priority bugs we've never paid
        attention to". Then time-box it if practical--say you'll spend no more than
        80 person-hours this sprint on all the little nagging crud your Product
        Owner wants taken care but that on its own (you're right) never makes it to
        the top of a priority list.

        --Mike Cohn
        Author of User Stories Applied for Agile Software Development
        www.userstories.com

        -----Original Message-----
        From: Greg [mailto:profos9@...]
        Sent: Wednesday, March 10, 2004 2:00 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] RE: What to do with "loose ends"

        I want to thank everyone for your great responses to
        this topic. I've been working with Dennis on
        introducing Scrum into our organization and we have
        been very pleased with the results thus far.

        Before Dennis posted the question on "loose ends" we
        thought that it might come down to a simple question
        of priority and I guess that it stills does to an
        extent. But, one thing that I'm concerned about is
        that many of these issues are "rough edges" in (or on)
        the product. Individually, they can be easily
        overlooked and are of no consequence. However,
        collectively, these rough edges add up to a product
        that may be perceived as being unfinished or
        unrefined.

        So, if the "loose ends" are considered as individual
        items and prioritized as such they may never be
        addressed. Thus it would seem that this is when the
        collective nature of these "loose ends" is a problem.
        The end result being the product that is unrefined,
        unpolished and ready for prime time.

        Any thoughts?

        I think Charlie Trainor has a good point about quality
        and how those rough edges should be caught prior to
        the review. We obviously have some "opportunities"
        for improvement there.:) But, in the rush to meet the
        goals of the current sprint, how do you balance the
        quality issues (that create many of the loose ends)?


        I also liked Michael Hirsch's approach to bundling
        related ones into a single requirement. That may take
        care of a portion of your loose ends. But, what of
        the ones that don't bundle well? In a complex product
        that list may be significant.

        Has anyone just saved these up for a final (move to
        production) sprint and tried to resolve as many of
        these as can be done during that sprint? Or is that
        asking for trouble?

        Thanks again for all of your advice.

        Greg


        __________________________________
        Do you Yahoo!?
        Yahoo! Search - Find what youre looking for faster
        http://search.yahoo.com



        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links
      • Karl Scotland
        ... My first thought is why are there so many loose ends? As well as looking to catch them before the sprint review, could it also be because the team is
        Message 3 of 26 , Mar 11, 2004
          > -----Original Message-----
          > From: Greg [mailto:profos9@...]
          >
          > So, if the "loose ends" are considered as individual
          > items and prioritized as such they may never be
          > addressed. Thus it would seem that this is when the
          > collective nature of these "loose ends" is a problem.
          > The end result being the product that is unrefined,
          > unpolished and ready for prime time.
          >
          > Any thoughts?

          My first thought is why are there so many loose ends? As well as
          looking to catch them before the sprint review, could it also be because
          the team is commiting to too much in each sprint? What would happen if
          they commited to a little bit less so there's less of a rush to get
          things finished?

          Karl

          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
          stated.
          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.
        • Ken Schwaber
          Old habits die slowly. Teams still feel that it is their responsibility to diminish quality to increase functionality. Over and over, we discuss that quality
          Message 4 of 26 , Mar 11, 2004
            Old habits die slowly. Teams still feel that it is their responsibility to
            diminish quality to increase functionality. Over and over, we discuss that
            quality is invariant unless the customer so chooses.
            Ken

            -----Original Message-----
            From: Karl Scotland [mailto:karl.scotland@...]
            Sent: Thursday, March 11, 2004 5:25 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] RE: What to do with "loose ends"



            > -----Original Message-----
            > From: Greg [mailto:profos9@...]
            >
            > So, if the "loose ends" are considered as individual
            > items and prioritized as such they may never be
            > addressed. Thus it would seem that this is when the
            > collective nature of these "loose ends" is a problem.
            > The end result being the product that is unrefined,
            > unpolished and ready for prime time.
            >
            > Any thoughts?

            My first thought is why are there so many loose ends? As well as
            looking to catch them before the sprint review, could it also be because
            the team is commiting to too much in each sprint? What would happen if
            they commited to a little bit less so there's less of a rush to get
            things finished?

            Karl

            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
            stated.
            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@...
            Yahoo! Groups Links
          • PaulOldfield1@compuserve.com
            (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
            Message 5 of 26 , Mar 11, 2004
              (responding to Karl)

              > My first thought is why are there so many loose ends? As well
              > as looking to catch them before the sprint review, could it also
              > be because the team is commiting to too much in each sprint?
              > What would happen if they commited to a little bit less so
              > there's less of a rush to get things finished?

              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.

              Paul Oldfield
              www.aptprocess.com
            • Karl Scotland
              ... 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
              Message 6 of 26 , Mar 11, 2004
                > -----Original Message-----
                > From: PaulOldfield1@...
                >
                > (responding to Karl)
                >
                > > My first thought is why are there so many loose ends? As well
                > > as looking to catch them before the sprint review, could it also
                > > be because the team is commiting to too much in each sprint?
                > > What would happen if they commited to a little bit less so
                > > there's less of a rush to get things finished?
                >
                > 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.

                Karl

                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
                stated.
                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.
              • PaulOldfield1@compuserve.com
                (responding to Karl) ... Thanks, Karl; useful iformation. IIRC from your presentations, your interactive TV sounded like it was always in a rush and your
                Message 7 of 26 , Mar 12, 2004
                  (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".

                  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?


                  Paul Oldfield
                  www.aptprocess.com
                • Karl Scotland
                  Comments embedded below... ... 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
                  Message 8 of 26 , 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
                    visible.

                    > 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.

                    Karl

                    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
                    stated.
                    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.
                  • Kerri Rusnak
                    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
                    Message 9 of 26 , 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 :)

                       

                      - Kerri

                       

                       

                       

                      -----Original Message-----
                      From: Karl Scotland [mailto:karl.scotland@...]
                      Sent: Saturday, 13 March 2004 4:13 AM
                      To: scrumdevelopment@yahoogroups.com
                      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
                      visible.

                      > 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.

                      Karl

                      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
                      stated.
                      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@...




                    • Cook Linda
                      I have a recent experience with a team who was very conservative in their sprint committment. One contributing factor may be that they have seen other teams
                      Message 10 of 26 , Apr 1, 2004
                        I have a recent experience with a team who was very conservative in their
                        sprint committment. One contributing factor may be that they have seen
                        other teams workinglong hours to meet goals. The result was once the team
                        felt they could accomplish more they worked to add sprint goals. The team
                        met the original goals plus the goals that they added.
                        From my perspective, trustung in the team and a bit of faith in the process.
                        --------------------------
                        Sent from my BlackBerry Wireless Handheld
                      • J. B. Rainsberger
                        ... I find that when I get to work at my own pace for a while, then I start to feel like I have no real deadline, and as Peopleware taught us, the team without
                        Message 11 of 26 , Apr 1, 2004
                          Cook Linda wrote:

                          > I have a recent experience with a team who was very conservative in their
                          > sprint committment. One contributing factor may be that they have seen
                          > other teams workinglong hours to meet goals. The result was once the team
                          > felt they could accomplish more they worked to add sprint goals. The team
                          > met the original goals plus the goals that they added.
                          >>From my perspective, trustung in the team and a bit of faith in the process.

                          I find that when I get to work at my own pace for a while, then I start
                          to feel like I have no real deadline, and as Peopleware taught us, the
                          team without the deadline finishes first and best.
                          --
                          J. B. Rainsberger,
                          Diaspar Software Services
                          http://www.diasparsoftware.com :: +1 416 791-8603
                          Let's write software that people understand
                        Your message has been successfully submitted and would be delivered to recipients shortly.