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

RE: [XP] Continuous integration

Expand Messages
  • hubertsmits@if.com
    Hi Mike, Thanks for your long email and all the advise. I have adopted Scrum, although I have to make changes, due to the fact that the big design has already
    Message 1 of 13 , Sep 10, 2002
      Hi Mike,

      Thanks for your long email and all the advise. I have adopted Scrum,
      although I have to make changes, due to the fact that the big design has
      already finished. So I'm left with a coding and testing fase.

      I have indeed organised a 'scrum of scrums', with the first meeting
      yesterday and for the remainder of the project we meet every
      Monday/Wednesday/Friday, or more often if required. The teams organise their
      own scrums. My big challenge here is the commitment of the teamleaders:
      loads of chickens but few pigs. The commitment based management approach
      from my own company surely helps me to recognise this phenomenom and
      provides me with tools to approach the chickens, but given the tight
      schedule it does pose a real threat to the success of the project.

      I'm still working on the test approach. The company has a standard approach
      to a) unit test during development, b) path test post development, c)
      integration test, d) system test and e) acceptance test, all in a waterfall
      style. I'm getting buy-in to reduce this to continous integration testing
      and a seperate acceptance test. But nobody has experience with the
      continuous integration concept, so I'm sitting down later this week with the
      build team to organise this.

      It looks like I will have 2 sprints: one for the delivering functionality
      per team and one stabilisation sprint. The efforts per team don't exceed 4
      weeks, so that fits nicely in 1 sprint. But we are notoriously bad in using
      the testfase as a cushion to stretch the development time. A lot of my
      effort will go into motivating the teams to deliver 'zero defects'.

      The best thing I've done so far is buying a rugby ball and carrying the
      thing around to every meeting. That makes the project and the approach
      highly visible, which is good for motivation and commitment.

      Ok, back to the real world again where my development servers are planned to
      be delivered early December... I'm tempted to change the scrum approach to a
      baseball approach and swap the funny ball for a bat!

      Thanks again and I'll keep you posted.

      --Hubert

      -----Original Message-----
      From: Mike Cohn [mailto:mike@...]
      Sent: 09 September 2002 04:08
      To: extremeprogramming@yahoogroups.com
      Cc: HubertSmits@...
      Subject: RE: [XP] Continuous integration


      Hubert--

      Scrum may provide a solution, or at least a hint, for you. With Scrum
      you would have each of your 14 teams involved in their own iterations
      (Scrum calls them "sprints"). The teams meet daily in a "Scrum meeting,"
      which is pretty much your typical 15-minute standup meeting that is used
      to coordinate and communicate among team members. Additionally, there is
      a "Scrum of Scrums" which is a coordination effort one level above the
      teams--usually 1 representative of each team attends the Scrum of
      Scrums. Since you'd have a 14 person "scrum of scrums" you may want to
      have two 7-person scrums or break it some other way to avoid a 14-person
      "team".

      Jeff Sutherland has used "scrum of scrums" to scale up to over 800
      developers corporate-wide doing Scrum. I've used it with 120 developers.
      I don't know if Jeff's here but he's on the
      scrumdevelopment@yahoogroups.com list so you may want to see how he
      handled this if your teams are approaching the size he had.

      You are right that tests will break--even using a Scrum of Scrums
      approach. What I've found to work best in this situation is to allow
      each team to run at full speed (continuously integrating but concerned
      with only their own tests). Add to that a "nightly build and smoke test"
      that runs the more integration-oriented tests. My teams have typically
      set up rotating schedules around who is responsible for fixing these
      integration issues--e.g., Joe on Monday, Susan on Tuesday, etc. That
      person isn't necessarily the one who makes the code change but he or she
      owns the problem and makes sure that whoever can fix it knows about it
      and does.

      Another thing I've found useful with coordinated teams (my teams were in
      four US cities so this may be impacted by that) is that we found it
      necessary to introduce what we called "Stabilization Sprints" (perhaps
      if using XP we would have called them "Stabilization increments"). We
      would typically run 2-4 month-long sprints in the normal way EXCEPT that
      we would target "friendly first use" rather than shippable quality at
      the end of each sprint. This meant that we would have no reservations
      about shipping to friendly beta sites or such but that there were more
      integration tests or integration bugs or such that we wanted to fix
      before shipping a Generally Available release. During a stabilization
      sprint we still worked on items prioritized by our "customer" (a
      "Product Manager" as this was mostly commercial software) but those
      items were more things like "improve the customer search query
      performance" or "confirm that we'll work with an ABC100 machine" or even
      things like "write the overall install program" (since we sometimes
      needed all pieces done first). Since database changes were frequently
      the source of problems between teams we really tried to make sure none
      happened during a stabilization sprint.

      --Mike

      -----Original Message-----
      From: hubertsmits@... [mailto:hubertsmits@...]
      Sent: Friday, August 16, 2002 10:09 AM
      To: extremeprogramming@yahoogroups.com
      Subject: [XP] Continuous integration

      Guys,

      I've been trying to introduce some concepts if XP in my development
      team:
      early integration and continuous testing. I get objections around these
      two
      concepts: dependencies between delivered functionality of different
      teams
      will lead to very early breaking of the automated tests, leaving these
      tests
      useless. Eg. team 1 delivers new functionality that changes database
      tables.
      Team 2 hasn't included these db changes and has a capacity problem to do
      it
      early. All automated tests of team 2 will now fail.

      Is the solution to this problem that team 2 should reschedule priorities
      and
      does this lead to a chaotic scheduling of delivery priorities?

      Kind regards, Hubert

      Intelligent Finance is a division of Halifax plc, Registered in England
      No. 2367076, Registered Office: Trinity Road, Halifax, West Yorkshire
      HX1 2RG.



      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...

      ad-free courtesy of objectmentor.com

      Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/





      Intelligent Finance is a division of Halifax plc, Registered in England No. 2367076, Registered Office: Trinity Road, Halifax, West Yorkshire HX1 2RG.
    • Tommy Kelly
      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
      Message 2 of 13 , Sep 10, 2002
        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
      • 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.