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

RE: [scrumdevelopment] Meeting your goals by punting work items

Expand Messages
  • Wolfgang Schulze Zachau
    Some of your statements sound a bit odd to me. we don t always control our destiny when it comes to having control over our backlog. Which backlog? The team
    Message 1 of 18 , Dec 1, 2006
    • 0 Attachment
      Some of your statements sound a bit odd to me.
       
      we don't always control our destiny when it comes to
      having control over our backlog.
      Which backlog? The team has no control over the product backlog at all. The team has full control over the sprint backlog. If your team doesn't have full control over the sprint backlog, then why not? What is happening there ?
      Another side-effect is that writers
      are notoriously bad at predicting work load. We've tried adding in
      buffers to account for our ever-growing sprint backlog
      Why is your sprint backlog ever growing ? Who is adding to it ?
       
      I know I could draw a hard line and force the issue, but that
      makes the team extremely distressed. So many times, they've been
      heros and been able to get more work (albeit different work than
      planned) done in a typical sprint.
      Why is the team delivering stuff that was not planned? Do you do retrospectives? What happens during the retrospectives?
       

      Regards,

      Wolfgang

    • Steven Gordon
      ... Some of the key practices of Scrum are: - A story is not finished if any of its tasks are not finished (no punting), - Velocity for each sprint is
      Message 2 of 18 , Dec 1, 2006
      • 0 Attachment
        On 12/1/06, lisasolace <lsalas@...> wrote:
        >
        > We've been working as a scrum team for almost two years now, and the
        > one thing that continually ticks me off is that at the end of the
        > sprint, we end up punting all those items that were barely limping
        > along during the sprint, just so we can look like we're done with the
        > items in our backlog.
        >
        > We are a content development team that works on a continuous
        > publishing basis (releasing various pieces of content about once a
        > month) and we don't always control our destiny when it comes to
        > having control over our backlog. Another side-effect is that writers
        > are notoriously bad at predicting work load. We've tried adding in
        > buffers to account for our ever-growing sprint backlog - but
        > inevitably, we don't bump items back into the product backlog until
        > we see that it's absolutely hopeless 5 days before the end of the
        > sprint. I know I could draw a hard line and force the issue, but that
        > makes the team extremely distressed. So many times, they've been
        > heros and been able to get more work (albeit different work than
        > planned) done in a typical sprint.
        >
        > Am I just making too much out of meeting the goals we have planned -
        > even if we've planned equal amounts of work? Does it really matter
        > since we don't really need to hand off a completed product at the end
        > of a sprint?
        >

        Some of the key practices of Scrum are:
        - A story is not finished if any of its tasks are not finished (no punting),
        - Velocity for each sprint is determined by the value of just the
        stories that were completely finished during the sprint,
        - The velocity for the previouse sprints determines how much work is
        planned for the next sprint, so that planning is calibrated to what
        the team can actually accomplish. This reduces the number of
        unfinished tasks each sprint and the need for punting.

        Are you following the above practices?

        Steve
      • Ron Jeffries
        Hello, lisasolace. On Friday, December 1, 2006, at 1:44:11 PM, you ... If at the beginning of the sprint you sign up for N things, and then at the end you
        Message 3 of 18 , Dec 1, 2006
        • 0 Attachment
          Hello, lisasolace. On Friday, December 1, 2006, at 1:44:11 PM, you
          wrote:

          > We've been working as a scrum team for almost two years now, and the
          > one thing that continually ticks me off is that at the end of the
          > sprint, we end up punting all those items that were barely limping
          > along during the sprint, just so we can look like we're done with the
          > items in our backlog.

          If at the beginning of the sprint you sign up for N things, and then
          at the end you punt M things, thus completing only N-M, how does it
          "look like we're done with the items in [y]our backlog"?

          Ron Jeffries
          www.XProgramming.com
          The man happy in his work is not the narrow specialist,
          nor the well-rounded man, but the man who is doing
          what he loves to do. You must fall in love with some activity.
          --Richard P. Feynman
        • lisasolace
          ... the ... ...and therein lies the rub. We ll all agree on doing Nthings and we re gungho on getting those Nthings done. In the process of working on Nthings,
          Message 4 of 18 , Dec 1, 2006
          • 0 Attachment
            --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...>
            wrote:
            >
            > Hello, lisasolace. On Friday, December 1, 2006, at 1:44:11 PM, you
            > wrote:
            >
            > > We've been working as a scrum team for almost two years now, and the
            > > one thing that continually ticks me off is that at the end of the
            > > sprint, we end up punting all those items that were barely limping
            > > along during the sprint, just so we can look like we're done with
            the
            > > items in our backlog.
            >
            > If at the beginning of the sprint you sign up for N things, and then
            > at the end you punt M things, thus completing only N-M, how does it
            > "look like we're done with the items in [y]our backlog"?

            ...and therein lies the rub. We'll all agree on doing Nthings and we're
            gungho on getting those Nthings done. In the process of working on
            Nthings, we discover that we must add additional work items beyond the
            Nthings and the priority for those additional work items has now
            overtaken portions of those Nthings. Thus making the new group of work
            items called Mthings. Well the team doesn't want to punt the difference
            of Mthings-Nthings because, "what if we're able to get to them?"

            I guess it just seems to me that this is a simple case of changing
            requirements - and shouldn't I just be more vigilant about if something
            comes into the sprint backlog, something should get booted out to make
            room.
          • lisasolace
            ... the ... that ... end ... punting), ... Our stories are very broad and oftentimes, not well defined. This is a new theory for the team and we re having
            Message 5 of 18 , Dec 1, 2006
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, "Steven Gordon"
              <sgordonphd@...> wrote:
              >
              > On 12/1/06, lisasolace lsalas@... wrote:
              > >
              > > We've been working as a scrum team for almost two years now, and the
              > > one thing that continually ticks me off is that at the end of the
              > > sprint, we end up punting all those items that were barely limping
              > > along during the sprint, just so we can look like we're done with
              the
              > > items in our backlog.
              > >
              > > We are a content development team that works on a continuous
              > > publishing basis (releasing various pieces of content about once a
              > > month) and we don't always control our destiny when it comes to
              > > having control over our backlog. Another side-effect is that writers
              > > are notoriously bad at predicting work load. We've tried adding in
              > > buffers to account for our ever-growing sprint backlog - but
              > > inevitably, we don't bump items back into the product backlog until
              > > we see that it's absolutely hopeless 5 days before the end of the
              > > sprint. I know I could draw a hard line and force the issue, but
              that
              > > makes the team extremely distressed. So many times, they've been
              > > heros and been able to get more work (albeit different work than
              > > planned) done in a typical sprint.
              > >
              > > Am I just making too much out of meeting the goals we have planned -
              > > even if we've planned equal amounts of work? Does it really matter
              > > since we don't really need to hand off a completed product at the
              end
              > > of a sprint?
              > >
              >
              > Some of the key practices of Scrum are:
              > - A story is not finished if any of its tasks are not finished (no
              punting),
              > - Velocity for each sprint is determined by the value of just the
              > stories that were completely finished during the sprint,
              > - The velocity for the previouse sprints determines how much work is
              > planned for the next sprint, so that planning is calibrated to what
              > the team can actually accomplish. This reduces the number of
              > unfinished tasks each sprint and the need for punting.
              >
              > Are you following the above practices?
              >
              > Steve
              >

              Our stories are very broad and oftentimes, not well defined. This is a
              new theory for the team and we're having trouble integrating that
              methodology into our continuous publishing content model. We know our
              velocity in terms of single work items or tasks - and the team meets
              their expected velocity. It just happens to be on different work items
              than planned.
            • lisasolace
              ... all. The ... have ... there ... The sprint backlog morphs every sprint. It may be because our product owners never say no and we are a service oriented
              Message 6 of 18 , Dec 1, 2006
              • 0 Attachment
                --- In scrumdevelopment@yahoogroups.com, "Wolfgang Schulze Zachau"
                <wolfgang@...> wrote:
                >
                > Some of your statements sound a bit odd to me.
                >
                > we don't always control our destiny when it comes to
                > having control over our backlog.
                > Which backlog? The team has no control over the product backlog at
                all. The
                > team has full control over the sprint backlog. If your team doesn't
                have
                > full control over the sprint backlog, then why not? What is happening
                there
                > ?

                The sprint backlog morphs every sprint. It may be because our product
                owners never say no and we are a "service" oriented group. Or it may be
                because each of the team members take on (or flesh out) additional work
                that must be completed prior to the stories they have planned for the
                current sprint. It could be that we're at the mercy of outside forces
                having control over key pieces of dev process and can make or break our
                sprint.) I'm sure it's bits of all of these things. In any case, we plan
                our sprints with a 30% buffer to account for some of these issues.


                > Another side-effect is that writers
                > are notoriously bad at predicting work load. We've tried adding in
                > buffers to account for our ever-growing sprint backlog
                > Why is your sprint backlog ever growing ? Who is adding to it ?
                >
                > I know I could draw a hard line and force the issue, but that
                > makes the team extremely distressed. So many times, they've been
                > heros and been able to get more work (albeit different work than
                > planned) done in a typical sprint.
                >
                > Why is the team delivering stuff that was not planned? Do you do
                > retrospectives? What happens during the retrospectives?

                We have very good retrospectives and have used what we've learned from
                them to make better choices. Every sprint, we talk about not taking on
                additional work - but this is the one lesson we never,ever,ever seem to
                be able to apply. I hate to think I'm that incompetent, but when can you
                beat them over the head with the lesson-book?
                >
                >
                > Regards,
                >
                > Wolfgang
                >
              • Steven Gordon
                ... Then you just have to be explicit about what you did do and did not do, and make sure the product owner approves the tradeoffs. If your velocity is fairly
                Message 7 of 18 , Dec 1, 2006
                • 0 Attachment
                  On 12/1/06, lisasolace <lsalas@...> wrote:
                  >
                  > --- In scrumdevelopment@yahoogroups.com, "Steven Gordon"
                  > <sgordonphd@...> wrote:
                  >
                  > >
                  > > On 12/1/06, lisasolace lsalas@... wrote:
                  > > >
                  > > > We've been working as a scrum team for almost two years now, and the
                  > > > one thing that continually ticks me off is that at the end of the
                  > > > sprint, we end up punting all those items that were barely limping
                  > > > along during the sprint, just so we can look like we're done with
                  > the
                  > > > items in our backlog.
                  > > >
                  > > > We are a content development team that works on a continuous
                  > > > publishing basis (releasing various pieces of content about once a
                  > > > month) and we don't always control our destiny when it comes to
                  > > > having control over our backlog. Another side-effect is that writers
                  > > > are notoriously bad at predicting work load. We've tried adding in
                  > > > buffers to account for our ever-growing sprint backlog - but
                  > > > inevitably, we don't bump items back into the product backlog until
                  > > > we see that it's absolutely hopeless 5 days before the end of the
                  > > > sprint. I know I could draw a hard line and force the issue, but
                  > that
                  > > > makes the team extremely distressed. So many times, they've been
                  > > > heros and been able to get more work (albeit different work than
                  > > > planned) done in a typical sprint.
                  > > >
                  > > > Am I just making too much out of meeting the goals we have planned -
                  > > > even if we've planned equal amounts of work? Does it really matter
                  > > > since we don't really need to hand off a completed product at the
                  > end
                  > > > of a sprint?
                  > > >
                  > >
                  > > Some of the key practices of Scrum are:
                  > > - A story is not finished if any of its tasks are not finished (no
                  > punting),
                  > > - Velocity for each sprint is determined by the value of just the
                  > > stories that were completely finished during the sprint,
                  > > - The velocity for the previouse sprints determines how much work is
                  > > planned for the next sprint, so that planning is calibrated to what
                  > > the team can actually accomplish. This reduces the number of
                  > > unfinished tasks each sprint and the need for punting.
                  > >
                  > > Are you following the above practices?
                  > >
                  > > Steve
                  > >
                  >
                  > Our stories are very broad and oftentimes, not well defined. This is a
                  > new theory for the team and we're having trouble integrating that
                  > methodology into our continuous publishing content model. We know our
                  > velocity in terms of single work items or tasks - and the team meets
                  > their expected velocity. It just happens to be on different work items
                  > than planned.
                  >

                  Then you just have to be explicit about what you did do and did not
                  do, and make sure the product owner approves the tradeoffs.

                  If your velocity is fairly steady and you can offer the product owner
                  the ability to swap work mid-sprint, I see no problem unless the
                  product owner is dissatisfied.

                  Steve
                • Ron Jeffries
                  Hello, lisasolace. On Friday, December 1, 2006, at 2:43:28 PM, you ... Unless I m mistaken, in Scrum the Sprint backlog does not change during the Sprint. You
                  Message 8 of 18 , Dec 1, 2006
                  • 0 Attachment
                    Hello, lisasolace. On Friday, December 1, 2006, at 2:43:28 PM, you
                    wrote:

                    > I guess it just seems to me that this is a simple case of changing
                    > requirements - and shouldn't I just be more vigilant about if something
                    > comes into the sprint backlog, something should get booted out to make
                    > room.

                    Unless I'm mistaken, in Scrum the Sprint backlog does not change
                    during the Sprint. You might want to try working that way before
                    trying more advanced things.

                    Ron Jeffries
                    www.XProgramming.com
                    In times of stress, I like to turn to the wisdom of my Portuguese waitress,
                    who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
                    -- after Mark Vaughn, Autoweek.
                  • Nicholas Cancelliere
                    If you feel your stories are too broad then they probably are. Try breaking them down further using INVEST (Individual, Negotiable, Valuable, Estimate-able,
                    Message 9 of 18 , Dec 1, 2006
                    • 0 Attachment

                      If you feel your stories are too broad then they probably are.  Try breaking them down further using INVEST (Individual, Negotiable, Valuable, Estimate-able, Small and Testable).  

                      When you say that people meet their velocity on work items different than those planned - how are you calculating velocity?  You only earn credit for velocity by completing stories (requirements) that were planned.  Velocity is supposed to help you know what you can depend on - when a developer says he can deliver 3 stories he actually does so at the end of the timebox.  Using the velocity from past sprints helps you know what to predict in future knows - what the team actually can accomplish based on empirical data.

                      Are you also prioritizing your sprint backlog?  Developers ideally work down the sprint backlog in 1 to N priority.  If developers are cherry picking you have a problem.  If developers are working on stories not even scheduled in the iteration you got a problem.  Then the question is why is this happening, is there something wrong with your planning process?  How do you currently plan your iterations (sprints) and who attends them?

                      -Nick



                      On Dec 1, 2006, at 1:53 PM, lisasolace wrote:

                      Our stories are very broad and oftentimes, not well defined. This is a
                      new theory for the team and we're having trouble integrating that
                      methodology into our continuous publishing content model. We know our
                      velocity in terms of single work items or tasks - and the team meets
                      their expected velocity. It just happens to be on different work items
                      than planned.

                    • Mike Cohn
                      During sprint planning the team makes a commitment to deliver a set of Product Backlog Items (PBIs) that they choose with the product owner s guidance. During
                      Message 10 of 18 , Dec 1, 2006
                      • 0 Attachment
                        During sprint planning the team makes a commitment to deliver a set of Product Backlog Items (PBIs) that they choose with the product owner's guidance. During sprint planning they decompose those PBIs into a set of tasks called the sprint backlog. 

                        During the sprint work will emerge as the team's understanding of the PBIs they've committed to emerges. This means that the team should never fill up every known hour of available work--we know we'll uncover new things to do. Those items are put on the sprint backlog. An example I often give is of a team that selects a PBI about "creating a demographic search screen." They talk with the product who tells them the screen needs to allow searches on demographic fields such as address, first name, last name, date of birth, etc. Midway through the sprint the PO notices that the team has left out searching on middle initial and tells the team it was intended as part of the search. In most situations the team should be able to accommodate this (it's a few hours; I'm assuming the team is roughly "on track" when this is discovered). If the team is behind they may say, "Sorry but we're behind. We can add middle initial if we defer date of birth until next sprint."  But what if the PO told the team, "Uh, what you've got looks good but did I mention that demographic searching includes geospatial searching by latitude and longitude? I don't see that in here yet."  In that case the team would probably say, "No you didn't and perhaps we should have talked a _tiny bit_ more before we started but we clearly don't have room for that this sprint. Please add it to the product backlog." (And then the four-letter words would come out after the PO walked away to do so.)

                        Good Scrum teams acknowledge that their product backlog items (ideally, IMO, as user stories in most cases) contain some amount of uncertainty and always will. The cost of driving out 99% of uncertainty is often greater than the cost of an occasional misunderstanding. (And in this case I contend it would be.) Because of this, we accept that the uncertainty of the PBI will only emerge fully during the sprint. The team still commits to delivering the PBI but does so with everyone aware that the commitment is to PBI as generally understood. If that understanding shifts a little (we add the middle initial) the team is still committed to it (subject to being out of time) but when the understanding shifts dramatically everyone needs to understand that the PBI will not be completed. This can feel uncomfortable at first but some amount of this is desirable--if it never happens then it is likely that too much effort is spent in upfront understanding of the backlog.

                        Regards,

                        Mike Cohn
                        Author:
                          Agile Estimating and Planning
                          User Stories Applied
                        www.mountaingoatsoftware.com


                        On Dec 1, 2006, at 1:16 PM, Ron Jeffries wrote:

                        Hello, lisasolace. On Friday, December 1, 2006, at 2:43:28 PM, you
                        wrote:

                        > I guess it just seems to me that this is a simple case of changing
                        > requirements - and shouldn't I just be more vigilant about if something
                        > comes into the sprint backlog, something should get booted out to make
                        > room.

                        Unless I'm mistaken, in Scrum the Sprint backlog does not change
                        during the Sprint. You might want to try working that way before
                        trying more advanced things.

                        Ron Jeffries
                        www.XProgramming.com
                        In times of stress, I like to turn to the wisdom of my Portuguese waitress,
                        who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
                        -- after Mark Vaughn, Autoweek.


                      • clintonnkeith
                        ... The Sprint backlog (tasks) can be changed by the team. The Sprint goals cannot.
                        Message 11 of 18 , Dec 1, 2006
                        • 0 Attachment
                          --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...>
                          wrote:

                          > Unless I'm mistaken, in Scrum the Sprint backlog does not change
                          > during the Sprint. You might want to try working that way before
                          > trying more advanced things.
                          >

                          The Sprint backlog (tasks) can be changed by the team. The Sprint goals
                          cannot.
                        • Michael James
                          ... One nit here: A Product Backlog Item is done when the Product Owner and Team agree its acceptance criteria are met. Pay attention to the story s
                          Message 12 of 18 , Dec 1, 2006
                          • 0 Attachment
                            --- In scrumdevelopment@yahoogroups.com, "Steven Gordon" <sgordonphd@...> wrote:
                            > Some of the key practices of Scrum are:
                            > - A story is not finished if any of its tasks are not finished (no punting),

                            One nit here: A Product Backlog Item is done when the Product Owner and Team agree its
                            acceptance criteria are met. Pay attention to the story's definition of "done." Looking
                            exclusively at the task status is misleading because they easily become misaligned with the
                            story.

                            --mj
                          • Ron Jeffries
                            Hello, clintonnkeith. On Friday, December 1, 2006, at 8:14:41 PM, ... I had the mistaken impression that your team was not meeting its sprint goals. Sorry.
                            Message 13 of 18 , Dec 1, 2006
                            • 0 Attachment
                              Hello, clintonnkeith. On Friday, December 1, 2006, at 8:14:41 PM,
                              you wrote:

                              >> Unless I'm mistaken, in Scrum the Sprint backlog does not change
                              >> during the Sprint. You might want to try working that way before
                              >> trying more advanced things.
                              >>

                              > The Sprint backlog (tasks) can be changed by the team. The Sprint goals
                              > cannot.

                              I had the mistaken impression that your team was not meeting its
                              sprint goals. Sorry.

                              Ron Jeffries
                              www.XProgramming.com
                              To follow the path:
                              Look to the master; Follow the master; Walk with the master;
                              See through the master; Become the master. -- Modern Zen Poem
                            • clintonnkeith
                              ... goals ... It had nothing to do with the question I was asking. You told Lisa Solace that the Sprint backlog does not change . You were mistaken. Re-read
                              Message 14 of 18 , Dec 1, 2006
                              • 0 Attachment
                                --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                <ronjeffries@...> wrote:
                                >
                                > Hello, clintonnkeith. On Friday, December 1, 2006, at 8:14:41 PM,
                                > you wrote:
                                >
                                > >> Unless I'm mistaken, in Scrum the Sprint backlog does not change
                                > >> during the Sprint. You might want to try working that way before
                                > >> trying more advanced things.
                                > >>
                                >
                                > > The Sprint backlog (tasks) can be changed by the team. The Sprint
                                goals
                                > > cannot.
                                >
                                > I had the mistaken impression that your team was not meeting its
                                > sprint goals. Sorry.
                                >

                                It had nothing to do with the question I was asking. You told Lisa
                                Solace that the "Sprint backlog does not change". You were mistaken.
                                Re-read the message you wrote:
                                http://groups.yahoo.com/group/scrumdevelopment/message/17764
                              • Ron Jeffries
                                Hello, clintonnkeith. On Friday, December 1, 2006, at 9:20:21 PM, ... I understand your point. I also understood Lisa to be saying that the team was subject
                                Message 15 of 18 , Dec 1, 2006
                                • 0 Attachment
                                  Hello, clintonnkeith. On Friday, December 1, 2006, at 9:20:21 PM,
                                  you wrote:

                                  > It had nothing to do with the question I was asking. You told Lisa
                                  > Solace that the "Sprint backlog does not change". You were mistaken.

                                  I understand your point. I also understood Lisa to be saying that
                                  the team was subject to external change, not just adding and
                                  removing tasks.

                                  And it seemed to me that they weren't getting done well, which does
                                  suggest that perhaps less change would be desirable.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  Analysis kills spontaneity.
                                  The grain once ground into flour germinates no more. -- Henri Amiel
                                • dnicolet99
                                  Steve s suggestion sounds really good to me. A few additional ideas come to mind. You say 1. you re delivering content (not software or some other sort of
                                  Message 16 of 18 , Dec 2, 2006
                                  • 0 Attachment
                                    Steve's suggestion sounds really good to me.

                                    A few additional ideas come to mind. You say

                                    1. you're delivering content (not software or some other sort of
                                    engineered product)

                                    2. there are frequent changes to stories, scope, priorities during the
                                    sprint

                                    3. you don't necessarily deliver anything into production at the end
                                    of a sprint

                                    4. stories are often very general at the outset of a sprint, and you
                                    discover the details as you go along.

                                    With those four points in mind, maybe it would be feasible to shorten
                                    the length of the sprint.

                                    Since the product isn't software, you don't have to worry about
                                    squeezing any sort of formal QA testing in prior to the end of a
                                    sprint. Essentially, you can just stop when the Product Owner feels
                                    the story is done.

                                    With a shorter sprint, all the changes that inevitably occur to story
                                    scope and priorities would not have to be handled as on-the-fly
                                    adjustments, but could be planned out a little better (even if
                                    planning occurs faster and more frequently).

                                    It doesn't sound as if there's any pressing need to align the sprints
                                    with the approximately-monthly publication schedule. You could have
                                    several short sprints between publication dates.

                                    With shorter sprints, the effect of discovering the details of the
                                    stories on the amount of work delivered in a given sprint would be
                                    smaller, since you could "reset" and re-estimate more frequently. It's
                                    often easier to deal with new information about requirements during
                                    sprint planning than as a constant stream of changes mid-sprint.



                                    --- In scrumdevelopment@yahoogroups.com, "Steven Gordon"
                                    <sgordonphd@...> wrote:
                                    >
                                    > On 12/1/06, lisasolace <lsalas@...> wrote:
                                    > >
                                    > > --- In scrumdevelopment@yahoogroups.com, "Steven Gordon"
                                    > > <sgordonphd@> wrote:
                                    > >
                                    > > >
                                    > > > On 12/1/06, lisasolace lsalas@ wrote:
                                    > > > >
                                    > > > > We've been working as a scrum team for almost two years now,
                                    and the
                                    > > > > one thing that continually ticks me off is that at the end of the
                                    > > > > sprint, we end up punting all those items that were barely
                                    limping
                                    > > > > along during the sprint, just so we can look like we're done with
                                    > > the
                                    > > > > items in our backlog.
                                    > > > >
                                    > > > > We are a content development team that works on a continuous
                                    > > > > publishing basis (releasing various pieces of content about
                                    once a
                                    > > > > month) and we don't always control our destiny when it comes to
                                    > > > > having control over our backlog. Another side-effect is that
                                    writers
                                    > > > > are notoriously bad at predicting work load. We've tried
                                    adding in
                                    > > > > buffers to account for our ever-growing sprint backlog - but
                                    > > > > inevitably, we don't bump items back into the product backlog
                                    until
                                    > > > > we see that it's absolutely hopeless 5 days before the end of the
                                    > > > > sprint. I know I could draw a hard line and force the issue, but
                                    > > that
                                    > > > > makes the team extremely distressed. So many times, they've been
                                    > > > > heros and been able to get more work (albeit different work than
                                    > > > > planned) done in a typical sprint.
                                    > > > >
                                    > > > > Am I just making too much out of meeting the goals we have
                                    planned -
                                    > > > > even if we've planned equal amounts of work? Does it really
                                    matter
                                    > > > > since we don't really need to hand off a completed product at the
                                    > > end
                                    > > > > of a sprint?
                                    > > > >
                                    > > >
                                    > > > Some of the key practices of Scrum are:
                                    > > > - A story is not finished if any of its tasks are not finished (no
                                    > > punting),
                                    > > > - Velocity for each sprint is determined by the value of just the
                                    > > > stories that were completely finished during the sprint,
                                    > > > - The velocity for the previouse sprints determines how much
                                    work is
                                    > > > planned for the next sprint, so that planning is calibrated to what
                                    > > > the team can actually accomplish. This reduces the number of
                                    > > > unfinished tasks each sprint and the need for punting.
                                    > > >
                                    > > > Are you following the above practices?
                                    > > >
                                    > > > Steve
                                    > > >
                                    > >
                                    > > Our stories are very broad and oftentimes, not well defined. This
                                    is a
                                    > > new theory for the team and we're having trouble integrating that
                                    > > methodology into our continuous publishing content model. We know our
                                    > > velocity in terms of single work items or tasks - and the team meets
                                    > > their expected velocity. It just happens to be on different work
                                    items
                                    > > than planned.
                                    > >
                                    >
                                    > Then you just have to be explicit about what you did do and did not
                                    > do, and make sure the product owner approves the tradeoffs.
                                    >
                                    > If your velocity is fairly steady and you can offer the product owner
                                    > the ability to swap work mid-sprint, I see no problem unless the
                                    > product owner is dissatisfied.
                                    >
                                    > Steve
                                    >
                                  • clintonnkeith
                                    ... Rigth. It sounds as though the Sprint Goals are changing: Lisa wrote: In the process of working on Nthings, we discover that we must add additional
                                    Message 17 of 18 , Dec 2, 2006
                                    • 0 Attachment
                                      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                      <ronjeffries@...> wrote:
                                      >
                                      > Hello, clintonnkeith. On Friday, December 1, 2006, at 9:20:21 PM,
                                      > you wrote:
                                      >
                                      > > It had nothing to do with the question I was asking. You told Lisa
                                      > > Solace that the "Sprint backlog does not change". You were mistaken.
                                      >
                                      > I understand your point. I also understood Lisa to be saying that
                                      > the team was subject to external change, not just adding and
                                      > removing tasks.
                                      >
                                      > And it seemed to me that they weren't getting done well, which does
                                      > suggest that perhaps less change would be desirable.
                                      >

                                      Rigth. It sounds as though the "Sprint Goals" are changing:

                                      Lisa wrote:
                                      "In the process of working on Nthings, we discover that we must add
                                      additional work items beyond the Nthings and the priority for those
                                      additional work items has now overtaken portions of those Nthings"

                                      Which shouldn't happen. The "Sprint backlog", list of tasks that the
                                      team originally broke down to fullfill the Sprint goals can often
                                      change as the team works on the goals. Limiting change there might
                                      prevent the goals from being accomplished.
                                    Your message has been successfully submitted and would be delivered to recipients shortly.