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

Re: [scrumdevelopment] dependancies

Expand Messages
  • Ron Jeffries
    ... 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
    Message 1 of 19 , Sep 15, 2003
      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
    • 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 2 of 19 , Sep 15, 2003
        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 3 of 19 , Sep 15, 2003
          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 4 of 19 , Sep 15, 2003
            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 5 of 19 , Sep 15, 2003
              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 6 of 19 , Sep 15, 2003
                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 7 of 19 , Sep 15, 2003
                  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 8 of 19 , Sep 16, 2003
                    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 9 of 19 , Sep 16, 2003
                      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 10 of 19 , Sep 16, 2003
                        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 11 of 19 , Sep 16, 2003
                          <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 12 of 19 , Sep 18, 2003
                            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 13 of 19 , Sep 18, 2003

                              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 14 of 19 , Sep 18, 2003
                                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 15 of 19 , Sep 18, 2003
                                  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 16 of 19 , Sep 18, 2003
                                    >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 17 of 19 , Sep 19, 2003
                                      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 18 of 19 , Sep 19, 2003
                                        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.