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

Re: [scrumdevelopment] dependancies

Expand Messages
  • Ron Jeffries
    ... I think the dll feature isn t a feature, it s an implementation detail. Recall that in Scrum, when a feature is scheduled, the TEAM commits to the feature.
    Message 1 of 19 , Sep 15, 2003
    • 0 Attachment
      On Monday, September 15, 2003, at 10:33:53 PM, Mike wrote:

      > Thanks for the reply. Let me clarify my question:

      > Say you have component a.dll, developed by one programmer and an exe b.exe
      > which happens to be developed by a different programmer.

      > In the case where you need to add a feature where a.dll gets the feature and
      > b.exe gets to use that feature. That seems to me like a clear dependency
      > which is hard to ignore.

      > Customers ask for b.exe to have the end result feature, they don't
      > necessarily care what a.dll has or doesn't.

      > Because there doesn't seem to be a whole lot of dependencies usually I would
      > say that bumping up the priority of a.dll feature implementation would be
      > one way to do it...

      > What do you think about that approach?

      I think the dll feature isn't a feature, it's an implementation detail.
      Recall that in Scrum, when a feature is scheduled, the TEAM commits to the
      feature. So if b.exe's feature is scheduled, doing a.dll's task is part of
      the deal. The team figures this out -- it's how Scrum works.

      Does that make sense?

      Ron Jeffries
      www.XProgramming.com
      Do only what is necessary. Keep only what you need.
    • Bryan Zarnett
      ... Is your dependency based on your programmer-to-component binding or based on a architectural layer? I find often that these particular areas, when used to
      Message 2 of 19 , Sep 15, 2003
      • 0 Attachment
        On Monday, September 15, 2003, at 07:41 PM, Mike wrote:

        > I am curious how people reflect dependencies between tasks on SCRUM
        > backlog list.  It doesn’t seem like the backlog spreadsheets that I’ve
        > seen in the past had that information.
        >  

        Is your dependency based on your programmer-to-component binding or
        based on a architectural layer? I find often that these particular
        areas, when used to create tasks develop dependencies that are often
        not required if you approach the task from a more generalized point of
        view. Of course this has to do with the requirement definition in your
        product backlog. A non-functional requirement might be defined from an
        architectural point of view, but the tasks associated with the
        implementation of business logic; you might be able to write without
        concern of the architectural or design terminology.

        For example, in your sprint backlog...

        - Provide the ability to calculate the total account balance from the
        users bank accounts.

        Would describe a task.

        - Add to the financial calculator DLL a function to accumulate and
        total the account balances for a users card.
        - Call the accountBalance function from the calculator DLL through the
        Foo interface
        - Provide a UI to xxxxx

        Are implementation details of the task.

        If we had to write out the implementation details versus the task
        itself the list would be incredibly long and very silly. Why silly?
        Because most of the work would be written down in blocks as:

        - Create a model object to do the following
        - Create a data access logic component to insert the model object foo
        - Create a business entity component to represent the following XXX
        - Create a common object to do YYY
        - Create a dynamic page to display foo
        - Add to the configuration file XXX

        And so fourth.

        Just some thoughts. Please comment.

        Cheers,
        Bryan







        > By the way does someone keep the spreadsheet posted on their site
        > somewhere?  I can’t find it on the major SCRUM sites:
        > http://www.mountaingoatsoftware.com/scrum/ and
        > http://www.controlchaos.com

        If you go through the old yahoo archives there is a copy. A new copy of
        a Backlog spreadsheet is available to certified Scrum Masters through
        the Scrum Alliance.
      • Mike
        OK, just to make sure we cover all bases here if you do approach a task from a general point of view how do you: a) split that general task between 2 owners b)
        Message 3 of 19 , Sep 15, 2003
        • 0 Attachment
          OK, just to make sure we cover all bases here if you do approach a task from
          a general point of view how do you:
          a) split that general task between 2 owners
          b) keep the SCRUM-like tasks (1-3 work days).

          Thanks,
          mb

          -----Original Message-----
          From: Bryan Zarnett [mailto:bzarnett@...]
          Sent: Monday, September 15, 2003 8:20 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] dependancies


          On Monday, September 15, 2003, at 07:41 PM, Mike wrote:

          > I am curious how people reflect dependencies between tasks on SCRUM
          > backlog list.  It doesn’t seem like the backlog spreadsheets that I’ve
          > seen in the past had that information.
          >  

          Is your dependency based on your programmer-to-component binding or
          based on a architectural layer? I find often that these particular
          areas, when used to create tasks develop dependencies that are often
          not required if you approach the task from a more generalized point of
          view. Of course this has to do with the requirement definition in your
          product backlog. A non-functional requirement might be defined from an
          architectural point of view, but the tasks associated with the
          implementation of business logic; you might be able to write without
          concern of the architectural or design terminology.

          For example, in your sprint backlog...

          - Provide the ability to calculate the total account balance from the
          users bank accounts.

          Would describe a task.

          - Add to the financial calculator DLL a function to accumulate and
          total the account balances for a users card.
          - Call the accountBalance function from the calculator DLL through the
          Foo interface
          - Provide a UI to xxxxx

          Are implementation details of the task.

          If we had to write out the implementation details versus the task
          itself the list would be incredibly long and very silly. Why silly?
          Because most of the work would be written down in blocks as:

          - Create a model object to do the following
          - Create a data access logic component to insert the model object foo
          - Create a business entity component to represent the following XXX
          - Create a common object to do YYY
          - Create a dynamic page to display foo
          - Add to the configuration file XXX

          And so fourth.

          Just some thoughts. Please comment.

          Cheers,
          Bryan







          > By the way does someone keep the spreadsheet posted on their site
          > somewhere?  I can’t find it on the major SCRUM sites:
          > http://www.mountaingoatsoftware.com/scrum/ and
          > http://www.controlchaos.com

          If you go through the old yahoo archives there is a copy. A new copy of
          a Backlog spreadsheet is available to certified Scrum Masters through
          the Scrum Alliance.



          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/
        • Mike Beedle
          ... Ron: Long before XP was around Scrumers did just that. Back in 1995 when Bob Martin wrote his now famous book: [MartinR95] Robert C. Martin, Designing
          Message 4 of 19 , Sep 15, 2003
          • 0 Attachment
            Ron writes:
            > If I did Scrum instead of XP I would do just what I do in XP.
            >
            > 1. I ignore dependencies.
            > 2. I observe that customers usually ask for the right dependent
            > item first.
            > 3. I observe that they can usually be influenced to ask for
            > the right one if need be.
            > 4. I observe that dependencies are usually reversible, i.e. if
            > A and B are dependent such that A will take 5 days and then
            > B will only take 1, it's usually true that if B is done first,
            > it will take 5 days and then A only 1.
            > 5. I build the parts that dependent projects depend on incrementally.

            Ron:

            Long before XP was around Scrumers did just that.

            Back in 1995 when Bob Martin wrote his now famous book:

            [MartinR95] Robert C. Martin, Designing Object
            Oriented
            C++ Applications using the Booch Method", Prentice Hall,
            Englewood Cliffs, NJ 1995

            We had a lot of arguments about how would you plan for "dependencies".
            (Bob's book is a masterpiece in the analysis of such dependencies
            for _any_ languages as is his PPP book i.e. "Agile Software
            Development: Principles, Patterns and Practices."

            The conclusion that some of us made after literally years of
            discussions was that:

            You can't know up-front in Requirements component
            dependencies unless you already know the Design.

            But in most cases, and specially in _new development_ you
            won't "know" the design -- you are inventing it as a
            New Product (ala Nonaka and Takeuchi). Therefore,
            in Scrum we simply what the customer wants in prioritized
            form, and we self-organize to cope with the dependencies.

            This is one of the very important reasons why Scrum can't
            promise to deliver 100% of the scheduled functionality
            for a Sprint.... because there might be dependencies that
            make you deliver something first, on your way to what
            was the original goal!!!!

            But that's ok Scrum does promise you will deliver
            something meaningful, a contribution toward the goal,
            and that you will make the most of your time and effort
            to satisfy the customers' wishes,

            - Mike
          • David J. Anderson
            ... do in XP. ... I think that much of the confusion may come from the term task list and both the mental model that invokes and the baggage it carries from
            Message 5 of 19 , Sep 15, 2003
            • 0 Attachment
              Ron writes:
              > If I did Scrum instead of XP I would do just what I
              do in XP.
              >
              > 1. I ignore dependencies.
              > ....

              I think that much of the confusion may come from the
              term "task list" and both the mental model that
              invokes and the baggage it carries from PMI project
              management models.

              What Ron (and Mike B.) are describing is the notion
              that the Sprint Backlog is a list of client-valued
              functionality - or occasionally client-valued
              non-functionality (architectural features often
              referred to as "ilities").

              Hence, they aren't really tasks in the conventional
              sense. What many see as tasks are being described here
              as "implementation details".

              Perhaps the description of the Backlog as an "itemized
              list of valuable deliverables" or a "value list" would
              clear up the confusion.

              Regards,

              David




              =====
              David J Anderson
              Author of "Agile Management for Software Engineering"
              http://www.agilemanagement.net/

              __________________________________
              Do you Yahoo!?
              Yahoo! SiteBuilder - Free, easy-to-use web site design software
              http://sitebuilder.yahoo.com
            • Ron Jeffries
              ... I m sure that s why Beck modeled part of the XP Planning Game after Scrum. ;- Ron Jeffries www.XProgramming.com Steering is more important than speed, in
              Message 6 of 19 , Sep 16, 2003
              • 0 Attachment
                On Tuesday, September 16, 2003, at 12:26:06 AM, Mike Beedle wrote:

                > Long before XP was around Scrumers did just that.

                I'm sure that's why Beck modeled part of the XP Planning Game after Scrum.
                ;->

                Ron Jeffries
                www.XProgramming.com
                Steering is more important than speed,
                in driving and in software development.
              • Bryan Zarnett
                ... Why does the general task need to be split between two owners - are you keeping your component-to-developer relationship? If you have such a defined
                Message 7 of 19 , Sep 16, 2003
                • 0 Attachment
                  On Monday, September 15, 2003, at 11:35 PM, Mike wrote:

                  > OK, just to make sure we cover all bases here if you do approach a
                  > task from
                  > a general point of view how do you:
                  > a) split that general task between 2 owners

                  Why does the general task need to be split between two owners - are you
                  keeping your component-to-developer relationship? If you have such a
                  defined relationship that must be adhered too for political reasons
                  that the generalization of tasks might not work (might not). The
                  potential for mandatory binding of component-to-developer can create
                  impediments in your time line as well as place down a single-point of
                  failure.

                  Two people can work on a specific task. They can pair program or they
                  can split the responsibilities of a given task. This is part of the
                  group dynamics and communication within the team. Frank takes sprint
                  backlog item 'A'. In discussion about 'A' Frank says he needs 'Q' from
                  'A', so he will do 'Q'. In many circumstances, my sprint backlog is
                  big enough for everyone to take a task to work with not worrying about
                  who is assigned to a specific task.

                  I view a task description written in the sprint backlog as the
                  "essence" of the given action as described in Corps. Business.


                  > b) keep the SCRUM-like tasks (1-3 work days).
                  Do you mean, can such generalized tasks still be estimated within 1 to
                  3 working days? Sure, why not.

                  Cheers,
                  Bryan
                • Stephen Haberman
                  ... I ve been confused on this point; my first thought was that for a sprint, product backlog items were verbatim copied over into the sprint backlog for the
                  Message 8 of 19 , Sep 16, 2003
                  • 0 Attachment
                    On Mon, Sep 15, 2003 at 11:15:15PM -0700, David J. Anderson wrote:
                    > What Ron (and Mike B.) are describing is the notion that the
                    > Sprint Backlog is a list of client-valued functionality - or
                    > occasionally client-valued non-functionality (architectural
                    > features often referred to as "ilities").

                    I've been confused on this point; my first thought was that for a
                    sprint, product backlog items were verbatim copied over into the
                    sprint backlog for the team to work on for 30 days.

                    Which your paragraph above insinuates (that spring backlog, like
                    product backlog, is high-level functionality and non-functionality).

                    I had been thinking that this didn't sound quite right for awhile
                    now, and I found in the Scrum book (pg. 49) that it says the Scrum
                    team compiles a list of tasks to complete the sprint goal. And that
                    each task should be an estimated 4-6 hours in length.

                    This changes the picture to something like:

                    Product Backlog:
                    1. -ility
                    2. -ility
                    3. -ility
                    4. ...

                    Sprint Goal:
                    Provide the first two -ilities.

                    Sprint Backlog:
                    1. Task for -ility 1
                    2. Task for -ility 1
                    3. Task for -ility 1
                    4. Task for -ility 2
                    5. Task for -ility 2
                    6. Task for -ility 2

                    Am I getting the right idea?

                    Thanks,
                    Stephen
                  • Mike Beedle
                    The conclusion that some of us made after literally years of discussions was that: You can t know up-front in Requirements component
                    Message 9 of 19 , Sep 16, 2003
                    • 0 Attachment
                      <Mike Beedle wrote>
                      The conclusion that some of us made after literally years of
                      discussions was that:

                      You can't know up-front in Requirements component
                      dependencies unless you already know the Design.
                      </Mike Beedle wrote>


                      The other conclusion, of course, is that for a New Product
                      you don't really know the requirements either ;-)

                      A New Product needs to be researched, validated, tested,
                      and created _all at once_, that's why the metaphor of
                      *software* as a New Product, or *software development* as
                      New Product Development makes so much sense,

                      - Mike
                    • Tiseo, Paul
                      List: I d like to hear a response to Stephen question. Did I miss it? (I just got back to a mailbox with over a 1000+ emails, many spam, so I quickly concede
                      Message 10 of 19 , Sep 18, 2003
                      • 0 Attachment
                        List:

                        I'd like to hear a response to Stephen question. Did I miss it? (I just got
                        back to a mailbox with over a 1000+ emails, many spam, so I quickly concede
                        this might have been answered.)

                        _________________________________
                        Paul Tiseo, Systems Programmer
                        Research Computing Facility
                        Mayo Clinic Jacksonville, Griffin 371
                        tiseo123.paul456@...


                        -----Original Message-----
                        From: Stephen Haberman [mailto:stephen@...]
                        Sent: Tuesday, September 16, 2003 9:18 AM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: Re: [scrumdevelopment] dependencies

                        On Mon, Sep 15, 2003 at 11:15:15PM -0700, David J. Anderson wrote:
                        > What Ron (and Mike B.) are describing is the notion that the
                        > Sprint Backlog is a list of client-valued functionality - or
                        > occasionally client-valued non-functionality (architectural
                        > features often referred to as "ilities").

                        I've been confused on this point; my first thought was that for a
                        sprint, product backlog items were verbatim copied over into the
                        sprint backlog for the team to work on for 30 days.

                        Which your paragraph above insinuates (that spring backlog, like
                        product backlog, is high-level functionality and non-functionality).

                        I had been thinking that this didn't sound quite right for awhile
                        now, and I found in the Scrum book (pg. 49) that it says the Scrum
                        team compiles a list of tasks to complete the sprint goal. And that
                        each task should be an estimated 4-6 hours in length.

                        This changes the picture to something like:

                        Product Backlog:
                        1. -ility
                        2. -ility
                        3. -ility
                        4. ...

                        Sprint Goal:
                        Provide the first two -ilities.

                        Sprint Backlog:
                        1. Task for -ility 1
                        2. Task for -ility 1
                        3. Task for -ility 1
                        4. Task for -ility 2
                        5. Task for -ility 2
                        6. Task for -ility 2

                        Am I getting the right idea?

                        Thanks,
                        Stephen



                        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/
                      • Bryan Zarnett
                        I ve used the product backlog to define the functional and non-functional requirements of the system written in a form that distills the essence of what is
                        Message 11 of 19 , Sep 18, 2003
                        • 0 Attachment

                          List:

                          I'd like to hear a response to Stephen question. Did I miss it? (I just got
                          back to a mailbox with over a 1000+ emails, many spam, so I quickly concede
                          this might have been answered.)

                          _________________________________
                          Paul Tiseo, Systems Programmer
                          Research Computing Facility
                          Mayo Clinic Jacksonville, Griffin 371
                          tiseo123.paul456@...


                          -----Original Message-----
                          From: Stephen Haberman [mailto:stephen@...]
                          Sent: Tuesday, September 16, 2003 9:18 AM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] dependencies

                          On Mon, Sep 15, 2003 at 11:15:15PM -0700, David J. Anderson wrote:
                          > What Ron (and Mike B.) are describing is the notion that the
                          > Sprint Backlog is a list of client-valued functionality - or
                          > occasionally client-valued non-functionality (architectural
                          > features often referred to as "ilities").

                          I've been confused on this point; my first thought was that for a
                          sprint, product backlog items were verbatim copied over into the
                          sprint backlog for the team to work on for 30 days.

                          Which your paragraph above insinuates (that spring backlog, like
                          product backlog, is high-level functionality and non-functionality).

                          I had been thinking that this didn't sound quite right for awhile
                          now, and I found in the Scrum book (pg. 49) that it says the Scrum
                          team compiles a list of tasks to complete the sprint goal. And that
                          each task should be an estimated 4-6 hours in length.

                          This changes the picture to something like:

                          Product Backlog:
                          1. -ility
                          2. -ility
                          3. -ility
                          4. ...

                          Sprint Goal:
                          Provide the first two -ilities.

                          Sprint Backlog:
                          1. Task for -ility 1
                          2. Task for -ility 1
                          3. Task for -ility 1
                          4. Task for -ility 2
                          5. Task for -ility 2
                          6. Task for -ility 2

                          Am I getting the right idea?

                          Thanks,
                          Stephen



                          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/



                          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 Beedle
                          Stephen: In the conversation in previous messages about this there is some overloading of terms. I am almost sure David meant the ilitiy word, to mean
                          Message 12 of 19 , Sep 18, 2003
                          • 0 Attachment
                            Stephen:

                            In the conversation in previous messages about this there is some
                            overloading of terms. I am almost sure David meant the "ilitiy" word,
                            to mean "architectural features" only i.e. things like:

                            flexibliity
                            extensibility
                            composability
                            resilience
                            performance
                            etc.


                            Basically he was referring to the fact that the Sprint Backlog
                            could have tasks for "alitiies" and "ilities" :-)

                            Considering the above, your spreadsheets, or lists, should look
                            like:

                            ================================================================
                            Sprint Goal:
                            Make the system do X by providing the first two -Alities
                            and the first -Ility.

                            Product Backlog:
                            story allocated_to_sprint priority rough_estimate complete(2)
                            STORY1(1)
                            STORY2
                            STORY3
                            STORY4

                            Story Backlog (create a new sheet for each Sprint):
                            story task comments priority owner est1(3) est2 est3 ...
                            STORY1 Task 1 (4)
                            STORY1 Task 2
                            STORY2 Task 1
                            STORY2 Task 2
                            STORY2 Task 3

                            Acceptance Tests
                            story test_name test_description status (5)
                            STORY1 Test 1
                            STORY1 Test 2
                            STORY2 Test 1
                            STORY2 Test 2
                            STORY2 Test 3
                            ================================================================

                            NOTES:
                            (1) PRODUCT BACKLOG ITEM == FUNCTIONALITY == STORY == FEATURE
                            example:
                            The system should provide for invoicing for
                            PHI Access reports (an -Alitity, or
                            The system should be made out or reusable components
                            (an -Ility)
                            (2) Complete means passed ALL Acceptance Tests, it is basically
                            a summary of the acceptance test results for that story
                            (3) The "est" numbers are the daily estimates. They are used
                            to produce a "burndown" chart.
                            (4) SPRINT BACKLOG ITEM == TASK FOR PRODUCT BACKLOG ITEM allocated
                            for that Sprint
                            (5) passed/failed/not tested

                            I hope this helps,

                            - Mike
                          • Stephen Haberman
                            ... Thanks, Mike, that confirmed what I was thinking and added a lot of good information. I was confused on the alility/ility thing, but now I think I ve got
                            Message 13 of 19 , Sep 18, 2003
                            • 0 Attachment
                              On Thu, Sep 18, 2003 at 10:30:17AM -0500, Mike Beedle wrote:
                              > I hope this helps,

                              Thanks, Mike, that confirmed what I was thinking and added a lot of
                              good information. I was confused on the alility/ility thing, but now
                              I think I've got it:

                              -alility = functional requirement,
                              -ility = non-functional requirement,
                              both go in the product backlog

                              If I could ask for one more clarification, what are some examples of
                              tasks? I'm basically still wondering how fine-grained tasks are in
                              relation to the alilities/ilities of the product backlog.

                              E.g. a task could be "modify class X to do a, b, and c" or "modify
                              class X to have -alility/be -ility" or "modify layer Y to be
                              -ility"?

                              Or would any of these work, and it just depends on what discrete
                              amount of work can be scheduled in roughly 4-6 hours?

                              Thanks,
                              Stephen
                            • Mike Beedle
                              ... Stephen: Yes, this is correct, and anything that you think the project needs: Training Testing Change to new DB flavor System Documentation User
                              Message 14 of 19 , Sep 18, 2003
                              • 0 Attachment
                                >Thanks, Mike, that confirmed what I was thinking and added a lot of
                                >good information. I was confused on the alility/ility thing, but now I
                                >think I've got it:
                                >
                                > -alility = functional requirement,
                                >-ility = non-functional requirement,
                                >both go in the product backlog

                                Stephen:

                                Yes, this is correct, and anything that you think the project needs:

                                Training
                                Testing
                                Change to new DB flavor
                                System Documentation
                                User Documentation
                                etc.

                                It is open-ended.


                                > If I could ask for one more clarification, what are some examples of
                                > tasks? I'm basically still wondering how fine-grained tasks are in
                                > relation to the alilities/ilities of the product backlog.
                                >
                                > E.g. a task could be "modify class X to do a, b, and c" or "modify
                                > class X to have -alility/be -ility" or "modify layer Y to be -ility"?
                                >
                                > Or would any of these work, and it just depends on what discrete
                                > amount of work can be scheduled in roughly 4-6 hours?


                                Any of the above are valid. The true metric is that you want to break
                                down the Product Backlog Item in both meaningful atoms and small
                                enough to track progress i.e. 4-6 hours.

                                Here are some examples from one of current projects:

                                story task
                                Configuration of environments Setup development environment
                                Configuration of environments Setup test environment
                                Configuration of environments Write data backup and recovery scripts
                                Configuration of environments Update HACLIENTDATA script

                                Configuration of environments Setup training environment
                                Configuration of environments Setup production environment
                                Configuration of environments Adobe Reader on desktops
                                Configuration of environments Load data from "test" database
                                etc.

                                (We probably could have chunk it out even more.)

                                - Mike
                              • Ken Schwaber
                                Q. How many certified scrummasters does it take to change a lightbulb? A. An infinite number who would wait for the light bulb to do it itself through the
                                Message 15 of 19 , Sep 19, 2003
                                • 0 Attachment
                                  Q. How many certified scrummasters does it take to change a lightbulb?
                                  A. An infinite number who would wait for the light bulb to do it itself
                                  through the principles of self-organization and emergence.
                                  Ken
                                • Edmund Schweppe
                                  ... Alternative answer: One, but not until the team reports that darkness is an impediment to achieving the Scrum Goal. -- Edmund Schweppe -- schweppe@ieee.org
                                  Message 16 of 19 , Sep 19, 2003
                                  • 0 Attachment
                                    Ken Schwaber wrote:
                                    > Q. How many certified scrummasters does it take to change a lightbulb?
                                    > A. An infinite number who would wait for the light bulb to do it itself
                                    > through the principles of self-organization and emergence.

                                    Alternative answer:

                                    One, but not until the team reports that darkness is an impediment to
                                    achieving the Scrum Goal.

                                    --
                                    Edmund Schweppe -- schweppe@... -- http://schweppe.home.tiac.net
                                    The opinions expressed herein are at best coincidentally related to
                                    those of any past, present or future employer.
                                  Your message has been successfully submitted and would be delivered to recipients shortly.