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

Adjusting/Terminating Sprints

Expand Messages
  • Tommy Kelly
    In the black book, all of the Sprint Backlog graphs (figures 4.5 to 4.9) share a common characteristic. They all intercept the X axis at Day 30 or 31, never
    Message 1 of 13 , Sep 10, 2002
    • 0 Attachment
      In the black book, all of the Sprint Backlog graphs
      (figures 4.5 to 4.9) share a common characteristic.
      They all intercept the X axis at Day 30 or 31, never
      before, and never after. And that looks too good
      to be true.

      So suppose the Sprint Team decides, part way into
      the Sprint, that it will not be able to complete the
      outstanding work in the time available. They have
      the following choices:

      a. Dump some backlog (so that they reckon they
      *will* complete on time) without changing
      the Sprint Goal

      b. Dump some backlog (again, to meet the 30 day
      target) but now requiring a change to the
      Sprint Goal

      c. Just keep going, preserving both backlog and goal,
      and make the Sprint last longer than 30 days

      Questions:

      1. Which of the three are permitted?

      Of those:

      2. Which require approval from Product Owner
      or Scrum Master, and which can the team do
      unilaterally?

      3. Which is recommended?


      thanks,
      Tommy
    • Mike Cohn
      You want to choose option a-dump some backlog without changing the sprint goal but you do it in coordination with the Product Owner. For some organizations
      Message 2 of 13 , Sep 10, 2002
      • 0 Attachment

        You want to choose option a—dump some backlog without changing the sprint goal but you do it in coordination with the Product Owner. For some organizations this may mean you ask the PO which tasks he/she wants removed, for other organizations it may mean the team can decide and “ask” the PO if the selected items are OK. I’ve found it depends on how long the PO and the team have worked together and how much they communicated about the priorities going in.

         

        Table 4.1 (p. 77) shows a good example of this on day 18 when it says the team has underestimated the work and they meet with the PO to determine what to drop.

         

        You don’t really want to change the sprint goal and you never want to extend the date. A scrum project gets into a nice rhythm by delivering monthly. Developers get into this mode where they know it’s not acceptable to miss a date and if the team gives a date they will make it (even if that means making the “sprint goal” not each individual task). If you let things slide a day or two at a time you (a) lose that rhythm, (b) establish that it’s OK to slip (maybe true on sprint 1 but probably not later) and (c) you actually lose a lot of time as a 2 day slip in a sprint is really a 10% overrun (2 days / 20 days) which can add up.

         

        Now, here’s an example where I reworded a sprint goal! (Yes, it was cheating but I defend it.) Version 1.4 of a project was shipping and had been done by one good programmer who had inherited the program in rapid succession from three previous guys. 1.4 was good enough to ship but the company had no QA process except the programmer testing his own stuff and that wasn’t one of his strengths. I think there are 20,000 users of this product right now but the plan is it will go over a million within a year (this is realistic, as it’s replacing a product with that many users). We started a sprint with the goal “make a rock-solid 1.5 release.” Right before then I’d got the company to hire a tester and he started the sprint with plans to put a good testing discipline onto the project. As soon as we started to get some real good testing we changed the sprint goal to be “make progress toward a rock-solid 1.5 release by testing and fixing bugs in areas A, B and C”.  It had become clear that a “rock solid 1.5” was 2-3 sprints away, not one. Until we started testing we couldn’t have really estimated how long the test effort would take and what it would find. We hadn’t committed a 1.5 as coming out in a month (1.4 had just been released, we were trying to get 1.5 ready before our customers needed it) so we were able to change the sprint goal pretty easily. This team is just a week into the second sprint on 1.5 and are making good progress toward the original sprint goal but doing it during this sprint. So, there’s an example of where I changed the sprint goal but doing that didn’t change anything about what we were working on, doing day-to-day or even about what the PO expected.

         

        --Mike

         

        -----Original Message-----
        From: Tommy Kelly [mailto:tommyk@...]
        Sent:
        Tuesday, September 10, 2002 8:55 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Adjusting/Terminating Sprints

         

        In the black book, all of the Sprint Backlog graphs
        (figures 4.5 to 4.9) share a common characteristic.
        They all intercept the X axis at Day 30 or 31, never
        before, and never after.  And that looks too good
        to be true. 

        So suppose the Sprint Team decides, part way into
        the Sprint, that it will not be able to complete the
        outstanding work in the time available.  They have
        the following choices:

           a. Dump some backlog (so that they reckon they
              *will* complete on time) without changing
              the Sprint Goal

           b. Dump some backlog (again, to meet the 30 day
              target) but now requiring a change to the
              Sprint Goal

           c. Just keep going, preserving both backlog and goal,
              and make the Sprint last longer than 30 days

        Questions:

           1. Which of the three are permitted?

        Of those:

           2. Which require approval from Product Owner
              or Scrum Master, and which can the team do
              unilaterally?

           3. Which is recommended?


        thanks,
        Tommy




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


        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      • John Goodsen
        I m curious - Is anyone using XPlanner to help manage distributed SCRUM teams? -- John Goodsen RADSoft / Rapid Software Delivery Specialists
        Message 3 of 13 , Sep 10, 2002
        • 0 Attachment
          I'm curious - Is anyone using XPlanner to help manage distributed
          SCRUM teams?

          --
          John Goodsen RADSoft / Rapid Software Delivery Specialists
          jgoodsen@... eXtreme Java Internet Consultants
          http://www.radsoft.com Toll Free: 866-RADSOFT (723-7638)
        • Mike Cohn
          I read it s homepage and was very intrigued but since I ve already got Oracle and SQL Server all over my machines I didn t have time to install another
          Message 4 of 13 , Sep 10, 2002
          • 0 Attachment

            I read it’s homepage and was very intrigued but since I’ve already got Oracle and SQL Server all over my machines I didn’t have time to install another database and check it out.

             

            I track things mostly via Excel spreadsheet but am currently configuring a defect tracker (TestTrack from Seapine) to track my sprints for me.

             

            Have you used XPlanner? How good is it?

             

            --Mike

             

            -----Original Message-----
            From: John Goodsen [mailto:jgoodsen@...]
            Sent: Tuesday, September 10, 2002 10:56 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Maintaining Product Backlog estimates

             

            I'm curious - Is anyone using XPlanner to help manage distributed
            SCRUM teams?

            --
            John Goodsen           RADSoft / Rapid Software Delivery Specialists
            jgoodsen@...             eXtreme Java Internet Consultants
            http://www.radsoft.com           Toll Free: 866-RADSOFT (723-7638)


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


            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          • John Goodsen
            (Hi Mike - how s your mock injection going? ;-) Yes - we use XPlanner for distributed teams - I think there is a Oracle user out there somewhere. It s not as
            Message 5 of 13 , Sep 10, 2002
            • 0 Attachment
              (Hi Mike - how's your mock injection going? ;-)

              Yes - we use XPlanner for distributed teams - I think there is a Oracle
              user out there somewhere. It's not as handy as index cards but
              when your customer is somewhere else or part of the team is
              somewhere else, it really helps close the gap well:

              It's easy to setup and get running if you have a Tomcat server
              up and running...

              http://xplanner.sourceforge.net

              --
              John Goodsen RADSoft / Rapid Software Delivery Specialists
              jgoodsen@... eXtreme Java Internet Consultants
              http://www.radsoft.com Toll Free: 866-RADSOFT (723-7638)


              Mike Cohn wrote:
              > I read it's homepage and was very intrigued but since I've already got
              > Oracle and SQL Server all over my machines I didn't have time to install
              > another database and check it out.
              >
              >
              >
              > I track things mostly via Excel spreadsheet but am currently configuring
              > a defect tracker (TestTrack from Seapine) to track my sprints for me.
              >
              >
              >
              > Have you used XPlanner? How good is it?
              >
              >
              >
              > --Mike
              >
              >
              >
              > -----Original Message-----
              > From: John Goodsen [mailto:jgoodsen@...]
              > Sent: Tuesday, September 10, 2002 10:56 AM
              > To: scrumdevelopment@yahoogroups.com
              > Subject: Re: [scrumdevelopment] Maintaining Product Backlog estimates
              >
              >
              >
              > I'm curious - Is anyone using XPlanner to help manage distributed
              > SCRUM teams?
            • Mike Cohn
              Convincing that group about mock objects hasn t gone so well yet. I showed them your example of mocking out the database in the login code. They didn t see the
              Message 6 of 13 , Sep 11, 2002
              • 0 Attachment

                Convincing that group about mock objects hasn’t gone so well yet. I showed them your example of mocking out the database in the login code. They didn’t see the value. I finally got them to understand that if each successive layer in an app is tested then the next layer only needs to test its own behavior—not everything beneath (e.g., the database). I’ll keep trying on them but for now I can’t convince them that they’re headed for trouble as the time it takes to run their unit tests gets very lengthy. Ugh.

                 

                I’ve added XPlanner to my “check it out” list and will get to it as soon as I can. I never use index cards as my teams always seem to be distributed. I’ve actually never got the appeal to them when I’ve got a perfectly fine computer in front of me.

                 

                --Mike

                 

                -----Original Message-----
                From: John Goodsen [mailto:jgoodsen@...]
                Sent: Tuesday, September 10, 2002 11:48 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: Re: [scrumdevelopment] Maintaining Product Backlog estimates

                 

                (Hi Mike - how's your mock injection going? ;-)

                Yes - we use XPlanner for distributed teams - I think there is a Oracle
                user out there somewhere.  It's not as handy as index cards but
                when your customer is somewhere else or part of the team is
                somewhere else, it really helps close the gap well:

                It's easy to setup and get running if you have a Tomcat server
                up and running...

                http://xplanner.sourceforge.net

                --
                John Goodsen           RADSoft / Rapid Software Delivery Specialists
                jgoodsen@...             eXtreme Java Internet Consultants
                http://www.radsoft.com           Toll Free: 866-RADSOFT (723-7638)


                Mike Cohn wrote:
                > I read it's homepage and was very intrigued but since I've already got
                > Oracle and SQL Server all over my machines I didn't have time to install
                > another database and check it out.
                >
                >
                >
                > I track things mostly via Excel spreadsheet but am currently configuring
                > a defect tracker (TestTrack from Seapine) to track my sprints for me.
                >
                >
                >
                > Have you used XPlanner? How good is it?
                >
                >
                >
                > --Mike
                >
                >
                >
                > -----Original Message-----
                > From: John Goodsen [mailto:jgoodsen@...]
                > Sent: Tuesday, September 10, 2002 10:56 AM
                > To: scrumdevelopment@yahoogroups.com
                > Subject: Re: [scrumdevelopment] Maintaining Product Backlog estimates
                >
                >
                >
                > I'm curious - Is anyone using XPlanner to help manage distributed
                > SCRUM teams?


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


                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
              • Ken Schwaber
                Tommy, The Product Backlog is maintained as often as needed by the product owner in response to changes in product requirements dictated by changes in the
                Message 7 of 13 , Sep 15, 2002
                • 0 Attachment
                  Tommy,
                  The Product Backlog is maintained as often as needed by the product owner in
                  response to changes in product requirements dictated by changes in the
                  business, changes in competition, changes regarding what will provide the
                  most value, changes in technology ... the product backlog is meant to evolve
                  as the technology, team, and business requirements evolve, so that the value
                  of each deliverable is optimized. The product backlog is usually maintained
                  on a public server, visible to all, at which the product owner can provide
                  realtime updates. The product backlog is only affected by the sprint backlog
                  at the end of each Sprint, when the uncompleted product backlog from that
                  sprint is put back on the product backlog and reprioritized. The product
                  backlog selected at the start of each sprint is used as a basis, or starting
                  point, for creating the sprint backlog.

                  Yes, the initial sprint backlog is often decomposed into >N tasks.

                  Product backlog consists of functional and non-functional requirements, that
                  is, what is needed in the product or system. The sprint backlog consists of
                  the tasks that the team figures they will need to do to turn the product
                  backlog into working product functionality.

                  Ken Schwaber

                  -----Original Message-----
                  From: Tommy Kelly [mailto:tommyk@...]
                  Sent: Tuesday, September 10, 2002 8:59 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: [scrumdevelopment] Maintaining Product Backlog estimates


                  The black book recommends that the Product Owner updates
                  the Product Backlog estimates on a weekly basis.
                  How is this done considering that:

                  a. The PO may be a customer,
                  who isn't on site on a weekly basis
                  and
                  b. Even if the PO *is* on site, the only
                  information available will be that
                  obtained by *listening* (I'm assuming that
                  the PO is a chicken) at Daily Scrums.
                  (And the three questions don't include
                  "how long do you estimate is remaining
                  for Sprint Backlog item X").

                  While I'm here, I'm assuming that the Sprint
                  Backlog of N items may be decomposed into
                  >N tasks. Yes?

                  If so, do team members claim ownership of Sprint
                  Backlog items, or of the constituent tasks?

                  thanks,
                  Tommy



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

                  Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                • Ken Schwaber
                  Thanks, Mike. Right on. Ken ... From: Mike Cohn [mailto:mike@mountaingoatsoftware.com] Sent: Tuesday, September 10, 2002 10:07 AM To:
                  Message 8 of 13 , Sep 15, 2002
                  • 0 Attachment
                    Thanks, Mike. Right on.
                    Ken
                    -----Original Message-----
                    From: Mike Cohn [mailto:mike@...]
                    Sent: Tuesday, September 10, 2002 10:07 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: RE: [scrumdevelopment] Maintaining Product Backlog estimates

                    First, on many of the projects I’ve done the Product Owner ends up not being a customer because on commercial products it just isn’t feasible. On projects delivering software for internal it’s much more viable and I have done that—on the other hand, even then, it usually ends up being the Scrum Master who updates backlogs.  As a ScrumMaster I will typically make sure backlog estimates are up to date and then I make sure the team (including the Product Owner) has the new information.

                     

                    I may has glossed over the exact wording in the book but it probably says that the Sprint Backlog (not the Product Backlog) is updated weekly. Sprint Backlog is the items selected for completion in the current sprint; Product Backlog is everything left out. I update the Sprint Backlog at least once a week; I update the Product Backlog only in the week before we start planning the next sprint.

                     

                    Updating the Sprint Backlog is more of a continuous activity. I don’t really sit down and say “now I’m going to update all of the sprint backlog.” Rather, as I get new information from team members I update the backlog. I get the information from talking to each of the developers outside the daily Scrum meeting. I may talk to some but not all developers on a given day so I’ll update backlog items based on what they’ve said. Typically I’ll ask how much is left on a task (I *never* ask how much has been expended on a task because it’s irrelevant) but I may also hear that a task no one has started yet is going to be harder/easier than planned or that we forgot to add tasks onto the list.  You also pick up stuff during the daily Scrum that can help you update the Sprint Backlog. You’ll certainly hear a programmer say things like “I finished the search screen yesterday so today I’m going to start on the search-results screen and with any luck I’ll finish that today.”  The daily scrum is all about commitments from one individual to the team so you hear what they finished (estimates on those go to 0 obviously!) and you hear what they’re doing today (which gives you some guidance about how long is left, sometimes enough to put in a guess for the remaining duration).

                     

                    Yes, a Sprint backlog of N tasks becomes at least N tasks. (It may be N.)

                     

                    More and more lately I’ve been using XP-style stories as my Product Backlog items and then when those Stories move into Sprints they are decomposed into tasks. The Product Backlog has things other than just Stories because Scrum isn’t as maniacally focused on the same goals as XP but the majority of my Product Backlog items are becoming User Stories. Other items like, “Document the design of the data storage classes” or “Speed up the customer query” are on there.

                     

                    --Mike

                     

                    -----Original Message-----
                    From: Tommy Kelly [mailto:tommyk@...]
                    Sent: Tuesday, September 10, 2002 6:59 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: [scrumdevelopment] Maintaining Product Backlog estimates

                     

                    The black book recommends that the Product Owner updates
                    the Product Backlog estimates on a weekly basis.
                    How is this done considering that:

                          a. The PO may be a customer,
                             who isn't on site on a weekly basis
                    and
                          b. Even if the PO *is* on site, the only
                             information available will be that
                             obtained by *listening* (I'm assuming that
                             the PO is a chicken) at Daily Scrums.
                             (And the three questions don't include
                              "how long do you estimate is remaining
                               for Sprint Backlog item X").

                    While I'm here, I'm assuming that the Sprint
                    Backlog of N items may be decomposed into
                    >N tasks.  Yes?

                    If so, do team members claim ownership of Sprint
                    Backlog items, or of the constituent tasks?

                    thanks,
                    Tommy



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


                    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.




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


                    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                  Your message has been successfully submitted and would be delivered to recipients shortly.