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

What to do with "loose ends"

Expand Messages
  • dennis
    We have been running SCRUM for about 5 months know. We have been successful at delivering functionality in each of the Sprints we have put together. The
    Message 1 of 26 , Mar 9, 2004
    • 0 Attachment

      We have been running SCRUM for about 5 months know. We have been successful at delivering functionality in each of the Sprints we have put together. The business is very pleased at the results as well.

       

      There is one nagging issue that has seemed to slowly expand over time. At the end of a Sprint as we are testing and demo’ing to the business, we identify several small items that need to be “fixed”: move this button here, change the color of this field, etc. All of these things end up on a “loose ends” list. They accumulate in a spreadsheet where we try to track them.

       

      The issue is that because they aren’t attached to a requirement anymore, they don’t seem to get the priority they should in a sprint. Yet they are things that need to be resolved.

       

      My question for the group is, does anyone else have a similar list at the end of a Sprint? If so how do you handle them? What process do you use to track them? Where do they fit in the priority of everything else? Should they be a separate Sprint or be at the top of the list at the beginning of the Sprint?

       

      Part of these I think I know the answer to, but I’m looking for experiences of others in this group and how they have handled it in the past.

       

      Thanks to all!

       

      Regards,

       

      Dennis Todd

       

    • Ron Jeffries
      ... Why doesn t the Product Manager just decide what sprint to put them in? Ron Jeffries www.XProgramming.com Hope is not a strategy. -- Michael Henos
      Message 2 of 26 , Mar 9, 2004
      • 0 Attachment
        On Tuesday, March 9, 2004, at 7:29:40 AM, dennis wrote:

        > My question for the group is, does anyone else have a similar list at the
        > end of a Sprint? If so how do you handle them? What process do you use to
        > track them? Where do they fit in the priority of everything else? Should
        > they be a separate Sprint or be at the top of the list at the beginning of
        > the Sprint?

        Why doesn't the Product Manager just decide what sprint to put them in?

        Ron Jeffries
        www.XProgramming.com
        Hope is not a strategy. -- Michael Henos
      • dhostick
        We are currently using SCRUM and XP. Development is managed using a tool called XPlanner, where Sprints are referred to as Iterations. We create an Iteration
        Message 3 of 26 , Mar 9, 2004
        • 0 Attachment
          We are currently using SCRUM and XP. Development is managed using a
          tool called XPlanner, where Sprints are referred to as Iterations.

          We create an Iteration called "Product Backlog", with other iterations
          named after their "Sprint Goal".

          During a Sprint, if anyone should want to raise a change (idea, bug --
          anything), a task is either added to an existing (and appropriate)
          User Story (Sprint Item) within the current sprint (with a low
          priority), or is added to the Product Backlog (to an existing or new
          User Story).

          At the end of the Sprint, the "loose ends" are moved to the Product
          Backlog and are prioritised accordingly for inclusion (or not) in the
          next Sprint. In XPlanner, you can continue or move Tasks and User
          Stories to other iterations (Sprints).

          This is also a really neat way of managing changes (requested by
          anyone) to the product - never say "No" if you can say "Low" (priority).

          Dave Hostick
        • Mike Cohn
          I m at a company where we have to do our sprint planning a few hours before we do the sprint review of the prior sprint. A bit backwards but we make it work.
          Message 4 of 26 , Mar 9, 2004
          • 0 Attachment
            I'm at a company where we have to do our sprint planning a few hours before
            we do the sprint review of the prior sprint. A bit backwards but we make it
            work.

            During the sprint review we always come up with a few tiny things--rephrase
            this, can you make that more prominent, etc.

            After the sprint review is over the team looks at that list and almost
            always pulls those items into the sprint they've just planned. Our feeling
            is that we can't estimate accurately enough that at the start of a sprint we
            can say "nope, that 3 hours of small trivial stuff will push us over the
            feasibility edge." So, we bring it in and it almost always gets done.

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


            -----Original Message-----
            From: dennis [mailto:dennistodd@...]
            Sent: Tuesday, March 09, 2004 5:30 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] What to do with "loose ends"

            We have been running SCRUM for about 5 months know. We have been successful
            at delivering functionality in each of the Sprints we have put together. The
            business is very pleased at the results as well.

            There is one nagging issue that has seemed to slowly expand over time. At
            the end of a Sprint as we are testing and demo'ing to the business, we
            identify several small items that need to be "fixed": move this button here,
            change the color of this field, etc. All of these things end up on a "loose
            ends" list. They accumulate in a spreadsheet where we try to track them.

            The issue is that because they aren't attached to a requirement anymore,
            they don't seem to get the priority they should in a sprint. Yet they are
            things that need to be resolved.

            My question for the group is, does anyone else have a similar list at the
            end of a Sprint? If so how do you handle them? What process do you use to
            track them? Where do they fit in the priority of everything else? Should
            they be a separate Sprint or be at the top of the list at the beginning of
            the Sprint?

            Part of these I think I know the answer to, but I'm looking for experiences
            of others in this group and how they have handled it in the past.

            Thanks to all!

            Regards,

            Dennis Todd
          • Steven Gordon
            Yes, but is it not true that these low priority loose ends tend to stay in the Product Backlog forever? That was what I understood to be the original
            Message 5 of 26 , Mar 9, 2004
            • 0 Attachment
              Yes, but is it not true that these low priority "loose ends" tend to stay in the "Product Backlog" forever? That was what I understood to be the original question.

              -----Original Message-----
              From: dhostick [mailto:dave@...]
              Sent: Tue 3/9/2004 7:58 AM
              To: scrumdevelopment@yahoogroups.com
              Cc:
              Subject: [scrumdevelopment] Re: What to do with "loose ends"


              We are currently using SCRUM and XP. Development is managed using a
              tool called XPlanner, where Sprints are referred to as Iterations.

              We create an Iteration called "Product Backlog", with other iterations
              named after their "Sprint Goal".

              During a Sprint, if anyone should want to raise a change (idea, bug --
              anything), a task is either added to an existing (and appropriate)
              User Story (Sprint Item) within the current sprint (with a low
              priority), or is added to the Product Backlog (to an existing or new
              User Story).

              At the end of the Sprint, the "loose ends" are moved to the Product
              Backlog and are prioritised accordingly for inclusion (or not) in the
              next Sprint. In XPlanner, you can continue or move Tasks and User
              Stories to other iterations (Sprints).

              This is also a really neat way of managing changes (requested by
              anyone) to the product - never say "No" if you can say "Low" (priority).

              Dave Hostick
            • Michael D. Hirsch
              ... When that happens, I ve occasionally grouped a whole bunch of loose ends into on item. That item then gets escalated. For instance, we had lots of poorly
              Message 6 of 26 , Mar 9, 2004
              • 0 Attachment
                On Tuesday 09 March 2004 10:51 am, Steven Gordon wrote:
                > Yes, but is it not true that these low priority "loose ends" tend to
                > stay in the "Product Backlog" forever? That was what I understood to
                > be the original question.

                When that happens, I've occasionally grouped a whole bunch of loose ends
                into on item. That item then gets escalated. For instance, we had
                lots of poorly phrased alerts and error messages. Each one wasn't
                enough to become high priority. But grouping 50 such messages together
                and they became a top priority.

                Michael

                > -----Original Message-----
                > From: dhostick [mailto:dave@...]
                > Sent: Tue 3/9/2004 7:58 AM
                > To: scrumdevelopment@yahoogroups.com
                > Cc:
                > Subject: [scrumdevelopment] Re: What to do with "loose ends"
                >
                >
                > We are currently using SCRUM and XP. Development is managed using a
                > tool called XPlanner, where Sprints are referred to as Iterations.
                >
                > We create an Iteration called "Product Backlog", with other
                > iterations named after their "Sprint Goal".
                >
                > During a Sprint, if anyone should want to raise a change (idea, bug
                > -- anything), a task is either added to an existing (and appropriate)
                > User Story (Sprint Item) within the current sprint (with a low
                > priority), or is added to the Product Backlog (to an existing or new
                > User Story).
                >
                > At the end of the Sprint, the "loose ends" are moved to the Product
                > Backlog and are prioritised accordingly for inclusion (or not) in
                > the next Sprint. In XPlanner, you can continue or move Tasks and User
                > Stories to other iterations (Sprints).
                >
                > This is also a really neat way of managing changes (requested by
                > anyone) to the product - never say "No" if you can say "Low"
                > (priority).
                >
                > Dave Hostick
                >
                >
                >
                >
                >
                > ------------------------ Yahoo! Groups Sponsor
                > ---------------------~--> KnowledgeStorm has over 22,000 B2B
                > technology solutions. The most comprehensive IT buyers' information
                > available. Research, compare, decide. E-Commerce | Application Dev |
                > Accounting-Finance | Healthcare | Project Mgt | Sales-Marketing |
                > More http://us.click.yahoo.com/IMai8D/UYQGAA/cIoLAA/9EfwlB/TM
                > ---------------------------------------------------------------------
                >~->
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@... Yahoo! Groups Links
                >
                >
                >
              • Ron Jeffries
                ... I m not sure what the Scrum handling is. I would think that low priority features, whether fixes or product ideas, stay /somewhere/ forever, and I d
                Message 7 of 26 , Mar 9, 2004
                • 0 Attachment
                  On Tuesday, March 9, 2004, at 10:51:17 AM, Steven Gordon wrote:

                  > Yes, but is it not true that these low priority "loose ends" tend to stay in the "Product Backlog" forever?
                  > That was what I understood to be the original question.

                  I'm not sure what the Scrum handling is. I would think that low priority
                  features, whether fixes or product ideas, stay /somewhere/ forever, and I'd
                  suppose it to be at the low end of the backlog.

                  Ron Jeffries
                  www.XProgramming.com
                  XP says: Don't just sit on your DUF, do something. Get some feedback.
                • Michael Feathers
                  ... RJ I m not sure what the Scrum handling is. I would think that low priority RJ features, whether fixes or product ideas, stay /somewhere/ forever, and
                  Message 8 of 26 , Mar 9, 2004
                  • 0 Attachment
                    >> Yes, but is it not true that these low priority "loose ends" tend to stay in the "Product Backlog" forever?
                    >> That was what I understood to be the original question.

                    RJ> I'm not sure what the Scrum handling is. I would think that low priority
                    RJ> features, whether fixes or product ideas, stay /somewhere/ forever, and I'd
                    RJ> suppose it to be at the low end of the backlog.

                    There's another possibility. You could just drop them after a few
                    sprints by convention. I can understand that being contentious but it
                    has its advantages. If an idea is really worthwhile, it will come up
                    again, and perhaps with enough passion and interest that next time for
                    it to become part of a sprint. If it never comes up again, it
                    probably means that it was a fluke.

                    I'd never do this without everyone's buy-in. When people propose
                    features they want to be heard, and recording the feature shows that.
                    On the other hand, I think there is a lot of misunderstanding that
                    happens on projects when people are heard and never realize, that hey,
                    nearly everything is higher priority than this and we just don't
                    happening. That is honest communication.

                    Aside from that, I think it is great for projects to wipe part of
                    their slate clean every once in a while. It lets people reevaluate
                    things afresh.

                    Michael Feathers
                    www.objectmentor.com
                  • dennis
                    Everyone s thoughts have been great so far. We know that at some point the business will probably say, we can t go live without this, but we can go live
                    Message 9 of 26 , Mar 9, 2004
                    • 0 Attachment

                       

                      Everyone’s thoughts have been great so far. We know that at some point the business will probably say, “we can’t go live without this, but we can go live without this”. So ultimately the “musts” have to be fixed.

                       

                      The “management” of them is the challenge. You can’t just drop them in somewhere and expect developers to make them a part of their everyday task. Keeping list helps, then there is the management of the list. Is it like a “backlog”? Hmmm! Kind of, but this backlog seems to have more overhead associated with it because each element is simple in it’s statement and thus requires more time to manage.

                       

                      I guess that is ultimately what I looking for is any recommendations of managing this list as efficiently as possible

                       

                      Dennis Todd

                       

                       

                       

                      On Tuesday, March 9, 2004, at 10:51:17 AM, Steven Gordon wrote:

                      > Yes, but is it not true that these low priority "loose ends" tend to stay in the "Product Backlog" forever?
                      > That was what I understood to be the original question.

                      I'm not sure what the Scrum handling is. I would think that low priority
                      features, whether fixes or product ideas, stay /somewhere/ forever, and I'd
                      suppose it to be at the low end of the backlog.

                      Ron Jeffries
                      www.XProgramming.com
                      XP says: Don't just sit on your DUF, do something. Get some feedback.



                      To Post a message, send it to:   scrumdevelopment@...
                      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



                    • Ron Jeffries
                      ... If I were to have an issue with this, it would be that it might encourage the customer to be a bit too careless. As long as the stuff is a few hours
                      Message 10 of 26 , Mar 9, 2004
                      • 0 Attachment
                        On Tuesday, March 9, 2004, at 10:34:27 AM, Mike Cohn wrote:

                        > I'm at a company where we have to do our sprint planning a few hours before
                        > we do the sprint review of the prior sprint. A bit backwards but we make it
                        > work.

                        > During the sprint review we always come up with a few tiny things--rephrase
                        > this, can you make that more prominent, etc.

                        > After the sprint review is over the team looks at that list and almost
                        > always pulls those items into the sprint they've just planned. Our feeling
                        > is that we can't estimate accurately enough that at the start of a sprint we
                        > can say "nope, that 3 hours of small trivial stuff will push us over the
                        > feasibility edge." So, we bring it in and it almost always gets done.

                        If I were to have an issue with this, it would be that it might encourage
                        the customer to be a bit too careless. As long as the stuff is a few hours'
                        worth, I'd not be troubled.

                        Ron Jeffries
                        www.XProgramming.com
                        My advice is to do it by the book, get good at the practices, then do as
                        you will. Many people want to skip to step three. That's OK too.
                      • Mike Cohn
                        Absolutely. Anything that is at all consequential we route back as story to be estimated and scheduled in. If it s hot then we have to redo a bit of the
                        Message 11 of 26 , Mar 9, 2004
                        • 0 Attachment
                          Absolutely. Anything that is at all consequential we route back as story to
                          be estimated and scheduled in. If it's "hot" then we have to redo a bit of
                          the sprint planning we'd already "finished." Otherwise, it just comes in a
                          later sprint. We're doing 2-week sprints so a delay is rarely a problem.

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


                          -----Original Message-----
                          From: Ron Jeffries [mailto:ronjeffries@...]
                          Sent: Tuesday, March 09, 2004 12:33 PM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] What to do with "loose ends"

                          On Tuesday, March 9, 2004, at 10:34:27 AM, Mike Cohn wrote:

                          > I'm at a company where we have to do our sprint planning a few hours
                          before
                          > we do the sprint review of the prior sprint. A bit backwards but we make
                          it
                          > work.

                          > During the sprint review we always come up with a few tiny
                          things--rephrase
                          > this, can you make that more prominent, etc.

                          > After the sprint review is over the team looks at that list and almost
                          > always pulls those items into the sprint they've just planned. Our feeling
                          > is that we can't estimate accurately enough that at the start of a sprint
                          we
                          > can say "nope, that 3 hours of small trivial stuff will push us over the
                          > feasibility edge." So, we bring it in and it almost always gets done.

                          If I were to have an issue with this, it would be that it might encourage
                          the customer to be a bit too careless. As long as the stuff is a few hours'
                          worth, I'd not be troubled.

                          Ron Jeffries
                          www.XProgramming.com
                          My advice is to do it by the book, get good at the practices, then do as
                          you will. Many people want to skip to step three. That's OK too.




                          To Post a message, send it to: scrumdevelopment@...
                          To Unsubscribe, send a blank message to:
                          scrumdevelopment-unsubscribe@...
                          Yahoo! Groups Links
                        • Deb
                          ... in? Yes, this is one of the more pernicious culture hang-overs to cure when you switch to Scrum. The urge to finish it . Mea culpa. However, now we are
                          Message 12 of 26 , Mar 9, 2004
                          • 0 Attachment
                            --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                            <ronjeffries@X...> wrote:
                            > On Tuesday, March 9, 2004, at 7:29:40 AM, dennis wrote:
                            >
                            > Why doesn't the Product Manager just decide what sprint to put them
                            in?

                            Yes, this is one of the more pernicious culture hang-overs to cure
                            when you switch to Scrum. The urge to "finish it". Mea culpa.

                            However, now we are about making things "sufficient" and then doing
                            the next important thing, right?

                            So the right thing to do is: create a backlog item for each loose
                            end, and let the customer prioritise them separately. When you ask
                            them: would they rather tweak the headers of 5 reports or add a
                            warning message to a critical window... whatever they pick is right.
                            And you do that next.

                            We must stop trying to perfect our work products, and instead work to
                            perfect the business of our clients. It's their call.

                            Somebody remind me, if I blow this again tomorrow!
                            :-)
                            deb

                            PS: we must get used to the possibility of a never-finishing backlog.
                            What gets to "finish" is the Sprint. As in life, the backlog will
                            always be there :-)
                          • Charlie Trainor
                            ... to stay in the Product Backlog forever? ... MF There s another possibility. You could just drop them after a few MF sprints by convention. I can
                            Message 13 of 26 , Mar 9, 2004
                            • 0 Attachment
                              >> Yes, but is it not true that these low priority "loose ends" tend
                              to stay in the "Product Backlog" forever?
                              >> That was what I understood to be the original question.

                              MF> There's another possibility. You could just drop them after a few
                              MF> sprints by convention. I can understand that being contentious
                              but it
                              MF> has its advantages. If an idea is really worthwhile, it will come
                              up
                              MF> again, and perhaps with enough passion and interest that next time
                              for
                              MF> it to become part of a sprint. If it never comes up again, it
                              MF> probably means that it was a fluke.

                              Absolutely, drop the stuff that clearly won't make it into a sprint in
                              the foreseeable future. In addition to the reasons Michael mentions,
                              it gets to be a big administrative burden to carry around an
                              ever-increasing backlog. And as the system grows and evolves, and
                              people's understanding grows, a lot of the backlog items would need to
                              be re-written anyway to make sense, even if they did become high
                              enough priority to make it into a sprint.

                              If you find yourself adding a lot of items to a backlog, and then
                              dumping them later as low priority, you'd be better off trying to
                              filter out more of those low priority items up front. There is a
                              natural tendency to want to capture every little idea and
                              nice-to-have - one of my current duties as product owner is to make
                              sure people concentrate on the core stuff, reassuring them that we'll
                              be in a much better position to understand and assess the importance
                              of the other stuff later in the project. I know that if the product
                              backlog gets too large, we will be just as likely to forget stuff
                              because we lose sight of it in a massive backlog as we would be to
                              forget it because it isn't there in the first place. This is a hard
                              nut for some people to swallow (and a good indication if they are
                              really getting into an agile mindset).

                              Getting back to the original problem Dennis raised, the goal is to
                              avoid having those little cleanup items in the first place. When
                              customers or testers are working closely with developers, most of
                              those little problems will get cleaned up
                              before the end-of-sprint demo. If the software really doesn't look
                              ready for prime time, a customer or tester will be more likely to say
                              "no, it isn't ready yet! Better fix it before showing it in the demo."
                              I've found it is obvious in a demo whether developers have been
                              working on their own, or have been getting good feedback from someone
                              with more of a business / end-user focus.

                              - Charlie
                            • Mike Cohn
                              I keep backlog items on note cards. If they are of such low priority I know I won t need them for awhile (or ever) I put a rubber band around them and just
                              Message 14 of 26 , Mar 9, 2004
                              • 0 Attachment
                                I keep backlog items on note cards. If they are of such low priority I know
                                I won't need them for awhile (or ever) I put a rubber band around them and
                                just keep them together. We keep all the backlog (in the form of XP-style
                                user stories) in a shoebox-sized rubbermaid box. Having an extra stack
                                rubber-banded together doesn't get in our way at all.

                                The cards are nice for all the well-known planning reasons: tactile,
                                tangible, multi-dimensional, etc. Also, we can sort them in a variety of
                                groupings whenever we want. We're going through them tomorrow sorting them
                                into "themes" that will drive the next few releases. During coming sprint
                                planning meetings we'll largely pull from the various theme piles. Of
                                course, if things change we can consider any story in the box but to get
                                anywhere near our big plans for the year we know we need to "spend about two
                                months on x" and "about a month on y" etc so we create a few rubber-banded
                                bundles from which we'll pull when those times comes.

                                I actually feel like my growing penchant for cards has me turning into Ron.
                                Today we had to plan a year's worth of growth in our data centers, which
                                entailed about 20 new servers. We used cards for this, too--one card per
                                computer and arranged them in visual layouts for their uses and in different
                                parts of the table to represent the different facilities involved.

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


                                -----Original Message-----
                                From: Charlie Trainor [mailto:charlie.trainor@...]
                                Sent: Tuesday, March 09, 2004 8:42 PM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: Re[2]: [scrumdevelopment] Re: What to do with "loose ends"

                                >> Yes, but is it not true that these low priority "loose ends" tend
                                to stay in the "Product Backlog" forever?
                                >> That was what I understood to be the original question.

                                MF> There's another possibility. You could just drop them after a few
                                MF> sprints by convention. I can understand that being contentious
                                but it
                                MF> has its advantages. If an idea is really worthwhile, it will come
                                up
                                MF> again, and perhaps with enough passion and interest that next time
                                for
                                MF> it to become part of a sprint. If it never comes up again, it
                                MF> probably means that it was a fluke.

                                Absolutely, drop the stuff that clearly won't make it into a sprint in
                                the foreseeable future. In addition to the reasons Michael mentions,
                                it gets to be a big administrative burden to carry around an
                                ever-increasing backlog. And as the system grows and evolves, and
                                people's understanding grows, a lot of the backlog items would need to
                                be re-written anyway to make sense, even if they did become high
                                enough priority to make it into a sprint.

                                If you find yourself adding a lot of items to a backlog, and then
                                dumping them later as low priority, you'd be better off trying to
                                filter out more of those low priority items up front. There is a
                                natural tendency to want to capture every little idea and
                                nice-to-have - one of my current duties as product owner is to make
                                sure people concentrate on the core stuff, reassuring them that we'll
                                be in a much better position to understand and assess the importance
                                of the other stuff later in the project. I know that if the product
                                backlog gets too large, we will be just as likely to forget stuff
                                because we lose sight of it in a massive backlog as we would be to
                                forget it because it isn't there in the first place. This is a hard
                                nut for some people to swallow (and a good indication if they are
                                really getting into an agile mindset).

                                Getting back to the original problem Dennis raised, the goal is to
                                avoid having those little cleanup items in the first place. When
                                customers or testers are working closely with developers, most of
                                those little problems will get cleaned up
                                before the end-of-sprint demo. If the software really doesn't look
                                ready for prime time, a customer or tester will be more likely to say
                                "no, it isn't ready yet! Better fix it before showing it in the demo."
                                I've found it is obvious in a demo whether developers have been
                                working on their own, or have been getting good feedback from someone
                                with more of a business / end-user focus.

                                - Charlie







                                To Post a message, send it to: scrumdevelopment@...
                                To Unsubscribe, send a blank message to:
                                scrumdevelopment-unsubscribe@...
                                Yahoo! Groups Links
                              • dave@hosticks.freeserve.co.uk
                                Well put Deb - I totally agree. Don t fight what will always happen - changing things for the better & not finishing something - will always be there... Dave
                                Message 15 of 26 , Mar 10, 2004
                                • 0 Attachment
                                  Well put Deb - I totally agree. Don't fight what will always happen - changing things for the better & not finishing something - will always be there...

                                  Dave


                                  > Message date : Mar 10 2004, 03:06 AM
                                  > From : "Deb" <deborah@...>
                                  > To : scrumdevelopment@yahoogroups.com
                                  > Copy to :
                                  > Subject : [scrumdevelopment] Re: What to do with "loose ends"
                                  >
                                  > <html><body>
                                  >
                                  >
                                  > <tt>
                                  > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <BR>
                                  > <ronjeffries@X...> wrote:<BR>
                                  > > On Tuesday, March 9, 2004, at 7:29:40 AM, dennis wrote:<BR>
                                  > > <BR>
                                  > > Why doesn't the Product Manager just decide what sprint to put them <BR>
                                  > in?<BR>
                                  > <BR>
                                  > Yes, this is one of the more pernicious culture hang-overs to cure <BR>
                                  > when you switch to Scrum. The urge to "finish it". Mea culpa.<BR>
                                  > <BR>
                                  > However, now we are about making things "sufficient" and then doing <BR>
                                  > the next important thing, right? <BR>
                                  > <BR>
                                  > So the right thing to do is: create a backlog item for each loose <BR>
                                  > end, and let the customer prioritise them separately. When you ask <BR>
                                  > them: would they rather tweak the headers of 5 reports or add a <BR>
                                  > warning message to a critical window... whatever they pick is right. <BR>
                                  > And you do that next.<BR>
                                  > <BR>
                                  > We must stop trying to perfect our work products, and instead work to <BR>
                                  > perfect the business of our clients. It's their call.<BR>
                                  > <BR>
                                  > Somebody remind me, if I blow this again tomorrow!<BR>
                                  > :-)<BR>
                                  > deb<BR>
                                  > <BR>
                                  > PS: we must get used to the possibility of a never-finishing backlog. <BR>
                                  > What gets to "finish" is the Sprint. As in life, the backlog will <BR>
                                  > always be there :-)<BR>
                                  > <BR>
                                  > <BR>
                                  > </tt>
                                  >
                                  > <br><br>
                                  > <tt>
                                  > To Post a message, send it to: scrumdevelopment@...<BR>
                                  > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...</tt>
                                  > <br><br>
                                  >
                                  > <br>
                                  >
                                  > <!-- |**|begin egp html banner|**| -->
                                  >
                                  > <table border=0 cellspacing=0 cellpadding=2>
                                  > <tr bgcolor=#FFFFCC>
                                  > <td align=center><font size="-1" color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
                                  > </tr>
                                  > <tr bgcolor=#FFFFFF>
                                  > <td align=center width=470><table><tr><td align=center><font face=arial size=-2>ADVERTISEMENT</font><br>
                                  > <IFRAME SRC="http://ad.doubleclick.net/adi/N3349.yahoo1/B1282054.27;sz=300x250;code=18634;dcopt=rcl;click=http://rd.yahoo.com/SIG=12c52q3ic/M=274551.4550177.5761904.1261774/D=egroupweb/S=1707209021:HM/EXP=1078969491/A=2019528/R=0/SIG=10o7l9qvh/*;ord=1078883091144561?" WIDTH=302 HEIGHT=252 MARGINWIDTH=0 MARGINHEIGHT=0 HSPACE=0 VSPACE=0 FRAMEBORDER=0 SCROLLING=no BORDERCOLOR='#000000'>
                                  > <SCRIPT language='JavaScript1.1' SRC="http://ad.doubleclick.net/adj/N3349.yahoo1/B1282054.27;abr=!ie;sz=300x250;code=18634;dcopt=rcl;click=http://rd.yahoo.com/SIG=12c52q3ic/M=274551.4550177.5761904.1261774/D=egroupweb/S=1707209021:HM/EXP=1078969491/A=2019528/R=1/SIG=10o7l9qvh/*;ord=1078883091144561?">
                                  > </script>
                                  > <NOSCRIPT>
                                  > <A HREF="http://rd.yahoo.com/SIG=12c52q3ic/M=274551.4550177.5761904.1261774/D=egroupweb/S=1707209021:HM/EXP=1078969491/A=2019528/R=2/SIG=141njbj5s/*http://ad.doubleclick.net/jump/N3349.yahoo1/B1282054.27;abr=!ie4;abr=!ie5;sz=300x250;code=18634;dcopt=rcl;ord=1078883091144561?">
                                  > <IMG SRC="http://ad.doubleclick.net/ad/N3349.yahoo1/B1282054.27;abr=!ie4;abr=!ie5;sz=300x250;code=18634;dcopt=rcl;ord=1078883091144561?" BORDER=0 WIDTH=300 HEIGHT=250 ALT="Click Here">Click Here</a>
                                  > </noscript>
                                  > </iframe>
                                  > </td></tr></table></td>
                                  > </tr>
                                  > <tr><td><img alt="" width=1 height=1 src="http://us.adserver.yahoo.com/l?M=274551.4550177.5761904.1261774/D=egroupweb/S=:HM/A=2019528/rand=478931144"></td></tr>
                                  > </table>
                                  >
                                  > <!-- |**|end egp html banner|**| -->
                                  >
                                  >
                                  >
                                  > <!-- |**|begin egp html banner|**| -->
                                  >
                                  > <br>
                                  > <tt><hr width="500">
                                  > <b>Yahoo! Groups Links</b><br>
                                  > <ul>
                                  > <li>To visit your group on the web, go to:<br><a href="http://groups.yahoo.com/group/scrumdevelopment/">http://groups.yahoo.com/group/scrumdevelopment/</a><br>
                                  > <li>To unsubscribe from this group, send an email to:<br><a href="mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe">scrumdevelopment-unsubscribe@yahoogroups.com</a><br>
                                  > <li>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.
                                  > </ul>
                                  > </tt>
                                  > </br>
                                  >
                                  > <!-- |**|end egp html banner|**| -->
                                  >
                                  >
                                  > </body></html>
                                  >
                                  >
                                  Freeserve AnyTime - HALF PRICE for the first 3 months - Save £7.50 a month
                                  www.freeserve.com/anytime
                                • 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 16 of 26 , Mar 10, 2004
                                  • 0 Attachment
                                    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 17 of 26 , Mar 10, 2004
                                    • 0 Attachment
                                      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 18 of 26 , Mar 11, 2004
                                      • 0 Attachment
                                        > -----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 19 of 26 , Mar 11, 2004
                                        • 0 Attachment
                                          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 20 of 26 , Mar 11, 2004
                                          • 0 Attachment
                                            (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 21 of 26 , Mar 11, 2004
                                            • 0 Attachment
                                              > -----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 22 of 26 , Mar 12, 2004
                                              • 0 Attachment
                                                (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 23 of 26 , Mar 12, 2004
                                                • 0 Attachment
                                                  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 24 of 26 , Apr 1, 2004
                                                  • 0 Attachment

                                                    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 25 of 26 , Apr 1, 2004
                                                    • 0 Attachment
                                                      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 26 of 26 , Apr 1, 2004
                                                      • 0 Attachment
                                                        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.