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

RE: [scrumdevelopment] dependancies

Expand Messages
  • Mike
    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
    Message 1 of 19 , Sep 15, 2003
    • 0 Attachment
      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?

      mb

      -----Original Message-----
      From: Ron Jeffries [mailto:ronjeffries@...]
      Sent: Monday, September 15, 2003 6:39 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] dependancies

      On Monday, September 15, 2003, at 7:41:55 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.

      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.

      Because there are all these options, I find that for planning purposes,
      rule 1 works quite well.

      Ron Jeffries
      www.XProgramming.com
      Think! -- Aretha Franklin



      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/
    • 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 2 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 3 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 4 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 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.
              > 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 6 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 7 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 8 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 9 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 10 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 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/
                        • 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 12 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 13 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 14 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 15 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 16 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 17 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.