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

RE: [scrumdevelopment] Maintaining Product Backlog estimates

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

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

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

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

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

        Questions:

        1. Which of the three are permitted?

        Of those:

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

        3. Which is recommended?


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

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

           

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

           

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

           

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

           

          --Mike

           

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

           

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

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

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

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

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

          Questions:

             1. Which of the three are permitted?

          Of those:

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

             3. Which is recommended?


          thanks,
          Tommy




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


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

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

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

               

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

               

              Have you used XPlanner? How good is it?

               

              --Mike

               

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

               

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

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


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


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

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

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

                http://xplanner.sourceforge.net

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


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

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

                   

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

                   

                  --Mike

                   

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

                   

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

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

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

                  http://xplanner.sourceforge.net

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


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


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


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

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

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

                    Ken Schwaber

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


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

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

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

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

                    thanks,
                    Tommy



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

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

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

                       

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

                       

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

                       

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

                       

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

                       

                      --Mike

                       

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

                       

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

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

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

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

                      thanks,
                      Tommy



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


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




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


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