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

RE: [scrumdevelopment] Maintaining Product Backlog estimates

Expand Messages
  • Mike Cohn
    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
    Message 1 of 13 , Sep 10, 2002

      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.
    • Tommy Kelly
      OK, but I think you are merging aspects of the Scrum Master and Product Owner roles. I doubt that s an issue, but as a newbie I m trying to take the book at
      Message 2 of 13 , Sep 10, 2002
        Message
        OK, but I think you are merging aspects of the Scrum Master
        and Product Owner roles.  I doubt that's an issue,
        but as a newbie I'm trying to take the book at its word and
        stick fairly rigidly to their precise approach for our first attempt.
         
        The section I'm referring to is section 4.5.2 on page 83.
        It says that the Product Owner updates the *Product* Backlog,
        not the Sprint Backlog, and that it's done weekly.
        That sounds strange to me - I'd have thought that only
        monthly updates were possible, since it is only
        at the end of sprint review meeting that the
        PO can then see which Sprint Backlog items have and have
        not been completed, and can transfer that info to the
        main Product Backlog.
         
        This is important to me because my probable PO is
        a guy working at another site.  It's infeasible for him to
        attend Daily Scrums nor, I gather, should that be required.
        Since the two granularities of meeting seem to be daily,
        or monthly, I'd have thought that the latter was the one
        for Product Backlog updates, and for Product Owner
        involvement with the team.
         
        t
         
         
         
        -----Original Message-----
        From: Mike Cohn [mailto:mike@...]
        Sent: 10 September 2002 15:07
        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.
      • Mike Cohn
        Yes, I merge parts of the Product Owner and Scrum Master roles on some (most) projects. It may be ideal to do it by the book but I rarely find a Product Owner
        Message 3 of 13 , Sep 10, 2002
          Message

          Yes, I merge parts of the Product Owner and Scrum Master roles on some (most) projects. It may be ideal to do it by the book but I rarely find a Product Owner willing to do everything required and it’s just easier to have the Scrum Master (sometimes me, sometimes a project manager) do it.

           

          Good points. I just dug out my little black book and re-read that section. I can see the mechanics of the updating—just add up what’s left in the sprint backlog and combine that with the product backlog. The product backlog may have had items added or removed but I certainly don’t ask my teams to go re-estimate the whole product backlog weekly. They’d kill me and it would be a waste of time. We do that monthly when it’s time to plan the next sprint. That means that only a little bit changes each week (current sprint, additions/deletions to product backlog), which is why I’ve never tracked it this way.

           

          Another problem is that this implies that I need to put much more serious consideration into the effort into things that are 5 sprints off. We don’t estimate such distant tasks with much effort so the margin of error on them is much, much greater than on current sprint tasks. In that sense I’d be adding pretty accurate numbers (tasks in this sprint) with some inaccurate ones and the variations I’d be graphing would just as likely be from changes in my perceptions about the project than from progress. Frequently in the first 1/3 of a project I can shave more time off the schedule by aggressively attacking the project’s major risks than I can by coding.

           

          You should be able to work with a remote Product Owner without any problem. Right now I am in Boulder, CO working with a team of developers in Sacramento, CA and with a Product Owner based out of San Diego, CA but who is most frequently found on an airplane to a customer site, prospect, or industry conference. It’s not always easy but it works.

           

          --Mike

           

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

           

          OK, but I think you are merging aspects of the Scrum Master

          and Product Owner roles.  I doubt that's an issue,

          but as a newbie I'm trying to take the book at its word and

          stick fairly rigidly to their precise approach for our first attempt.

           

          The section I'm referring to is section 4.5.2 on page 83.

          It says that the Product Owner updates the *Product* Backlog,

          not the Sprint Backlog, and that it's done weekly.

          That sounds strange to me - I'd have thought that only

          monthly updates were possible, since it is only

          at the end of sprint review meeting that the

          PO can then see which Sprint Backlog items have and have

          not been completed, and can transfer that info to the

          main Product Backlog.

           

          This is important to me because my probable PO is

          a guy working at another site.  It's infeasible for him to

          attend Daily Scrums nor, I gather, should that be required.

          Since the two granularities of meeting seem to be daily,

          or monthly, I'd have thought that the latter was the one

          for Product Backlog updates, and for Product Owner

          involvement with the team.

           

          t

           

           

           

          -----Original Message-----
          From: Mike Cohn [mailto:mike@...]
          Sent: 10 September 2002 15:07
          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.



          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.
        • 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 4 of 13 , Sep 10, 2002
            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 5 of 13 , Sep 10, 2002

              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 6 of 13 , Sep 10, 2002
                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 7 of 13 , Sep 10, 2002

                  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 8 of 13 , Sep 10, 2002
                    (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 9 of 13 , Sep 11, 2002

                      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 10 of 13 , Sep 15, 2002
                        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 11 of 13 , Sep 15, 2002
                          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.