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

dependancies

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

      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.

       

      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

       

       

       

       

    • 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 2 of 19 , Sep 15, 2003
      • 0 Attachment
        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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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.