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

Managing the Scrum backlogs...

Expand Messages
  • Steve Bannerman
    All, Linda Rising has been very helpful in reviewing my papers. She suggested that my topic area(s) is appropriate to this forum. I promise to work at
    Message 1 of 15 , Jun 27, 2003
    • 0 Attachment
      All,

      Linda Rising has been very helpful in reviewing my papers. She suggested
      that my topic area(s) is appropriate to this forum. I promise to work at
      reading some of the historical threads that are there so that you don't have
      to repeat everything for me.

      So, here goes (I apologize for the length of the post):

      Scrum Backlogs
      --
      From the documentation available on http://www.controlchaos.com/, it appears
      that there are three types of backlogs...one that represents all of the
      requirements (or features) for a product, a subset of those that are
      allocated to a specific Sprint, and then a subset of those that are
      allocated to the team on a daily basis.

      Hopefully this is correct, or at least reasonably so.

      So, my first question is, does the management of these backlogs fall inside
      the "black-box" or outside? If it's inside the black-box, then presumably
      the individuals within the black-box determine how to manage the backlog.
      Otherwise, I imagine that more prescriptive processes are recommended.

      My second question, having never executed a Scrum process, is how do you
      manage the different backlogs. When I say manage, how do you represent
      these requirements, how do you access them, how do you sort them, filter
      them, etc...

      Having some experience with XP (and I know that they're not mutually
      exclusive: XP@Scrum), and agile processes in general, I imagine that the
      goal is to have the simplest and most lightweight requirements and
      requirements processes as possible.

      A Middleweight Requirements Management Tool
      --

      In my opinion, requirements management has received a black eye because
      requirements are not accessible when you need them, rendering the
      requirements largely "irrelevant" after an initial read of the requirements
      document. This is the result of the "monolithic" requirements document and
      the poor choice of tool (Word or Excel).

      Also in my opinion, agile processes have rejected that "heavyweight stuff"
      and said that the only persistent artifact is the code (my paraphrase). Is
      this a case of "throwing the baby out with the bath water?" I say this
      because I don't think using things like index cards to represent
      requirements scales very well.

      Note that there are tools that represent the set of requirements at the
      right granularity (such as DOORS and Requisite Pro). However, these seem to
      either only be used by the requirements analysts or never get in the door to
      begin with, because of cost or complexity.

      So should requirements be "persistent" or not? I believe the should be, but
      I won't go into the reasons in this post. I also realize that this answer
      may be context dependent...on some projects they should be and on others
      they don't need to be.

      So, my proposal is that we (Scrum in particular) use a middleweight solution
      to manage the requirements (i.e. the different types of backlogs). This
      solution models the requirements at the same granularity as index cards...at
      the requirement level. Each requirement is stored in its own .xml file (a
      .rml file). This is simple (at least for developers as XML is pretty
      standard), flexible ("developers" can use any tool they wish to manipulate
      the files), and cheap (everybody has a file system and the tools will be
      free).

      The solution also provides tools with which to browse and transform these
      .rml files. And since they're "just files" we can use CVS (or an
      alternative) to provide configuration management. Since they're just files,
      the solution scales (in the sense that they can be backed up, viewed
      concurrently, filtered, sorted, and compared with automated processes.

      An Open Source Project
      --
      Sound interesting? I hope so. If so, check out the open source project
      that I've recently started. The only product available thus far is a Swing
      application that allows you to manage a set of .rml files on your local
      host. A Web application has been prototyped (but isn't yet available). And
      an Eclipse plugin is planned although development hasn't yet begun.

      http://163.1.27.165:8080/reqs - Open Source Project home page
      http://163.1.27.165:8080/reqs/products/swing.html - Download and
      Instructions for initial release of initial "product"

      I look forward to your comments, about managing the backlog in general,
      about using such a middleweight solution for doing so, and about the
      software products that help us do so.

      Finally, if anybody is interested in contributing to the project, be sure to
      let me know. Scrum would probably be a good choice for building an open
      source project!

      Cheers
      --
      Steve Bannerman
      steve.bannerman@...
      44.(0)1865.273866
    • Rick Innis
      ... As I understand it there are really only two backlogs, the project backlog and the spring backlog. Within the sprint backlog, the team members determine
      Message 2 of 15 , Jun 27, 2003
      • 0 Attachment
        > From the documentation available on http://www.controlchaos.com/, it
        > appears
        > that there are three types of backlogs...one that represents all of the
        > requirements (or features) for a product, a subset of those that are
        > allocated to a specific Sprint, and then a subset of those that are
        > allocated to the team on a daily basis.

        As I understand it there are really only two backlogs, the project
        backlog and the spring backlog. Within the sprint backlog, the team
        members determine which backlog items they're working on and when -
        no-one "allocates" backlog items to them. Remember, Scrum is about
        being agile and self-organising.

        > So, my first question is, does the management of these backlogs fall
        > inside
        > the "black-box" or outside? If it's inside the black-box, then
        > presumably
        > the individuals within the black-box determine how to manage the
        > backlog.
        > Otherwise, I imagine that more prescriptive processes are recommended.

        Again as I understand it, managing the backlog is part of the
        ScrumMaster's job. The daily scrum is an important part of managing the
        backlogs because it's the mechanism the ScrumMaster uses to track
        progress.

        To track the backlogs overall, an Excel spreadsheet is surprisingly
        useful. One of the beauties of Scrum is that it only requires
        lightweight management tools!

        --Rick
      • Julio Hartmann
        Hello All, In my development group, we are three project leaders running concurrent Scrums. One of us suggested that we should synchronize the Sprints. He says
        Message 3 of 15 , Jun 27, 2003
        • 0 Attachment
          Hello All,

          In my development group, we are three project leaders running concurrent
          Scrums. One of us suggested that we should synchronize the Sprints. He says
          this would allow us to evaluate, at the end of the Sprints, what is the most
          important projects for the company and if necessary, move people between the
          teams.
          Any experiences on the subject?

          Julio.
        • bschatz@primavera.com
          Julio, We just started using Scrum, but we have two major projects going on simultaneously, same product line, two different releases. We have 8 Scrum teams
          Message 4 of 15 , Jun 27, 2003
          • 0 Attachment
            Julio,

            We just started using Scrum, but we have two major projects going on
            simultaneously, same product line, two different releases. We have 8 Scrum
            teams and two product backlogs. We have the sprints synchronized (within a
            week) and we run a daily Scrum of Scrums everyday with the ScrumMasters. We
            are looking now at team compositions for the Sprint 2, and having them
            synchronized has allowed us to make team adjustments.

            Bob Schatz
            VP, Development
            Primavera Systems, Inc.



            "Julio Hartmann"
            <jhartmann@... To: <scrumdevelopment@yahoogroups.com>
            .br> cc:
            Subject: [scrumdevelopment] running multiple scrums
            06/27/2003 09:59
            AM
            Please respond to
            scrumdevelopment






            Hello All,

            In my development group, we are three project leaders running
            concurrent
            Scrums. One of us suggested that we should synchronize the Sprints. He says
            this would allow us to evaluate, at the end of the Sprints, what is the
            most
            important projects for the company and if necessary, move people between
            the
            teams.
            Any experiences on the subject?

            Julio.


            Yahoo! Groups Sponsor



            ADVERTISEMENT
            (Embedded image moved to file: pic27348.gif)


            (Embedded image moved to file: pic23199.gif)




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

            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          • Ken Schwaber
            Synchronizing to help evaluate Product Backlog functionality is great. Moving people between teams starts to break down the team productivity that the team
            Message 5 of 15 , Jun 27, 2003
            • 0 Attachment
              Synchronizing to help evaluate Product Backlog functionality is great. Moving people between teams starts to break down the team productivity that the team just built up over the last Sprint. Breaking teams up is an extreme move.
              Ken
              >
              > From: "Julio Hartmann" <jhartmann@...>
              > Date: 2003/06/27 Fri AM 07:59:46 CDT
              > To: <scrumdevelopment@yahoogroups.com>
              > Subject: [scrumdevelopment] running multiple scrums
              >
              > Hello All,
              >
              > In my development group, we are three project leaders running concurrent
              > Scrums. One of us suggested that we should synchronize the Sprints. He says
              > this would allow us to evaluate, at the end of the Sprints, what is the most
              > important projects for the company and if necessary, move people between the
              > teams.
              > Any experiences on the subject?
              >
              > Julio.
              >
              >
              >
              > 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/
              >
              >
              >
            • bschatz@primavera.com
              Clarification of our adjustments to teams... As Ken has stated yesterday in his message about large team size, which he was referring to a couple of our
              Message 6 of 15 , Jun 27, 2003
              • 0 Attachment
                Clarification of our adjustments to teams...

                As Ken has stated yesterday in his message about large team size, which he
                was referring to a couple of our teams...we had set up some oversized teams
                and as Ken mentioned, they self-organized and formed smaller sub-teams.
                That seemed to work, but there are still some significant communication
                break-downs, and daily sprints that go a little too long. So, for Sprint 2
                we will be breaking the two larger teams out into 5 separate small teams,
                in line with the way they chose to organize. We'll see how that goes. But
                we do want to keep the people together. After going through the cycle of
                learning how to work best with each other, which can be a distraction in
                itself, we don't want to have new teams forming every 30-days, so it is
                important to get the right team compositions as early as possible.





                Ken Schwaber
                <ken.schwaber@ver To: <scrumdevelopment@yahoogroups.com>
                izon.net> cc:
                Subject: Re: [scrumdevelopment] running multiple scrums
                06/27/2003 09:11
                AM
                Please respond to
                scrumdevelopment






                Synchronizing to help evaluate Product Backlog functionality is great.
                Moving people between teams starts to break down the team productivity that
                the team just built up over the last Sprint. Breaking teams up is an
                extreme move.
                Ken
                >
                > From: "Julio Hartmann" <jhartmann@...>
                > Date: 2003/06/27 Fri AM 07:59:46 CDT
                > To: <scrumdevelopment@yahoogroups.com>
                > Subject: [scrumdevelopment] running multiple scrums
                >
                > Hello All,
                >
                > In my development group, we are three project leaders running
                concurrent
                > Scrums. One of us suggested that we should synchronize the Sprints. He
                says
                > this would allow us to evaluate, at the end of the Sprints, what is the
                most
                > important projects for the company and if necessary, move people between
                the
                > teams.
                > Any experiences on the subject?
                >
                > Julio.
                >
                >
                >
                > 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/

                >
                >
                >


                Yahoo! Groups Sponsor

                (Embedded image moved to file: pic28476.gif)

                (Embedded image moved to file: pic27892.gif)




                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 Cohn
                It s nice to keep Scrum teams together if you can so I wouldn t move people around unless it was truly necessary or if projects were clearly
                Message 7 of 15 , Jun 27, 2003
                • 0 Attachment
                  It's nice to keep Scrum teams together if you can so I wouldn't move people
                  around unless it was truly necessary or if projects were clearly
                  overstaffed/understaffed.

                  However, I do think it's generally best to keep sprints synchronized. The
                  only time that wouldn't be the case is if the potentially shippable product
                  increments from all 3 teams are given to the same group for some further
                  processing. If synchronized they'd go to that group all at once and perhaps
                  bury them. For example, an external qa group wouldn't want to get hit with 3
                  products all at once. (Of course, the real advice then would be to split QA
                  into 3 and put some in each scrum team.)

                  -Mike

                  -----Original Message-----
                  From: Julio Hartmann [mailto:jhartmann@...]
                  Sent: Friday, June 27, 2003 7:00 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: [scrumdevelopment] running multiple scrums

                  Hello All,

                  In my development group, we are three project leaders running
                  concurrent
                  Scrums. One of us suggested that we should synchronize the Sprints. He says
                  this would allow us to evaluate, at the end of the Sprints, what is the most
                  important projects for the company and if necessary, move people between the
                  teams.
                  Any experiences on the subject?

                  Julio.



                  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/
                • bannerma
                  Rick, ... managing the ... Okay, so are you saying that the team members don t need to have access to the backlog, look at changes to it, filter for things
                  Message 8 of 15 , Jun 27, 2003
                  • 0 Attachment
                    Rick,

                    Thanks for your answers...replies below:

                    --- In scrumdevelopment@yahoogroups.com, Rick Innis <rick@i...>
                    wrote:
                    > .
                    > .
                    > .
                    >
                    > Again as I understand it, managing the backlog is part of the
                    > ScrumMaster's job. The daily scrum is an important part of
                    managing the
                    > backlogs because it's the mechanism the ScrumMaster uses to track
                    > progress.
                    >

                    Okay, so are you saying that the team members don't need to have
                    access to the backlog, look at changes to it, filter for things
                    assigned to them (if indeed that is tracked), sort on priority,
                    etc...

                    From my experience, a standup (which I've advocated and practiced
                    for many years) is a great opportunity to communicate at a high
                    level, identifying who needs to work on what and who needs to work
                    together that day (since there are interdependencies).

                    However, what gets allocated during standups is usually at that high
                    level. "Steve, you add support for creating a switch, including
                    automated tests that test it." The details of what it means to
                    create a switch are not communicated (otherwise the standups are a
                    lot longer than 15 minutes).

                    So is it correct to say that the backlog contains those high level
                    items (high level requirements)? If so, where does the assignee go
                    to get the details? Wouldn't it be nice to be able to use that high
                    level item itself as a portal to the details?

                    > To track the backlogs overall, an Excel spreadsheet is
                    surprisingly
                    > useful. One of the beauties of Scrum is that it only requires
                    > lightweight management tools!

                    Sure, I know that Excel spreadsheets are incredibly useful.
                    However, I really think that using them for requirements is
                    capturing them at the wrong level of granularity (i.e. one file for
                    a set of requirements).

                    Couldn't there also be a "lighweight" tool that manages the
                    requirements one per file? My experience with Excel is that it's
                    great for initial tasks but as "things" change (and they always do)
                    it's difficult to tell what exactly has changed.

                    What does a "lightweight" tool mean to you (and others in the group)?

                    Looking forward to your response(s).

                    Cheers

                    >
                    > --Rick
                  • Mike Cohn
                    There are two types of backlog: product backlog and sprint backlog. There are descriptions of each at www.mountaingoatsoftware.com/scrum, including pictures of
                    Message 9 of 15 , Jun 27, 2003
                    • 0 Attachment
                      There are two types of backlog: product backlog and sprint backlog. There
                      are descriptions of each at www.mountaingoatsoftware.com/scrum, including
                      pictures of each being tracked in Excel spreadsheets, which may be useful in
                      seeing how to use them.

                      -Mike

                      -----Original Message-----
                      From: Rick Innis [mailto:rick@...]
                      Sent: Friday, June 27, 2003 6:43 AM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: Re: [scrumdevelopment] Managing the Scrum backlogs...


                      > From the documentation available on http://www.controlchaos.com/, it
                      > appears
                      > that there are three types of backlogs...one that represents all of the
                      > requirements (or features) for a product, a subset of those that are
                      > allocated to a specific Sprint, and then a subset of those that are
                      > allocated to the team on a daily basis.

                      As I understand it there are really only two backlogs, the project
                      backlog and the spring backlog. Within the sprint backlog, the team
                      members determine which backlog items they're working on and when -
                      no-one "allocates" backlog items to them. Remember, Scrum is about
                      being agile and self-organising.

                      > So, my first question is, does the management of these backlogs fall
                      > inside
                      > the "black-box" or outside? If it's inside the black-box, then
                      > presumably
                      > the individuals within the black-box determine how to manage the
                      > backlog.
                      > Otherwise, I imagine that more prescriptive processes are recommended.

                      Again as I understand it, managing the backlog is part of the
                      ScrumMaster's job. The daily scrum is an important part of managing the
                      backlogs because it's the mechanism the ScrumMaster uses to track
                      progress.

                      To track the backlogs overall, an Excel spreadsheet is surprisingly
                      useful. One of the beauties of Scrum is that it only requires
                      lightweight management tools!

                      --Rick


                      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 Cohn
                      First, you need to understand a couple of fundamental things about Scrum so you can understand the rest: a) Scrum requires self-organizing teams. So, there is
                      Message 10 of 15 , Jun 27, 2003
                      • 0 Attachment
                        First, you need to understand a couple of fundamental things about Scrum so
                        you can understand the rest:

                        a) Scrum requires self-organizing teams. So, there is no allocation of tasks
                        during meetings. No, "Steve, you add support for...". Instead, team members
                        sign up for tasks.

                        b) In general, team members sign up for a task the day they start it, not in
                        advance. So, there's no real need to "sort on priority" or search for
                        assigned tasks, etc. During a sprint planning meeting a team will typically,
                        to some extent, "pre-signup" for work so they can determine if they're
                        bringing the right amount of work into the sprint. But that changes day to
                        day (perhaps not really during the first week or so) as learning about the
                        tasks occurs.

                        c) As others and I have said there are two backlogs: product and sprint.
                        Product backlog items might be "high level items" but sprint backlog are
                        tasks (not requirements per se) and are rarely more than 16 hours. Product
                        backlog items may be huge--I'll routinely have some big product backlog
                        tasks that we can't assess well (and time isn't worth spending on such an
                        effort). Those may be in as 100 days, for example.

                        d) The person working on a task (definitely never an "assignee") goes to the
                        "Product Owner" to find out the requirements. A Scrum team could perhaps use
                        a document to reflect the requirements of a given sprint but they are
                        generally trying to move too quickly and will instead prefer verbal
                        communication, much as with any of the other agile processes.

                        As to a lightweight tool: I'm intrigued by the use of tools for this purpose
                        but not so much for the day to day tracking of work left on a task or within
                        a sprint. The real value would more likely be found in organizing product
                        backlog items into release plans and also into being able to look back at
                        those over time. For example, we'll often start what we know will be a
                        multi-month project with just enough requirements to do the first sprint
                        (month). During the first month the Product Owner loads up the Product
                        Backlog. After a month we may work with the PO and determine an approximate
                        place we'll get to by the 5th sprint, at which point we'll release. But,
                        then after 4 months we might still be two (instead of 1) sprint away. It
                        would be nice to have a product that could show me (in soft of a visual diff
                        way) all the requirements that changed in priority, estimate, or are new.
                        That's the type of thing that is a bit hard in Excel. (I do it in Excel by
                        using a version control system, exporting spreadsheets to CSV files and then
                        using WinMerge as a good visual differencing tool).

                        I hope that helps,

                        -Mike

                        -----Original Message-----
                        From: bannerma [mailto:steve.bannerman@...]
                        Sent: Friday, June 27, 2003 8:00 AM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: [scrumdevelopment] Re: Managing the Scrum backlogs...

                        Rick,

                        Thanks for your answers...replies below:

                        --- In scrumdevelopment@yahoogroups.com, Rick Innis <rick@i...>
                        wrote:
                        > .
                        > .
                        > .
                        >
                        > Again as I understand it, managing the backlog is part of the
                        > ScrumMaster's job. The daily scrum is an important part of
                        managing the
                        > backlogs because it's the mechanism the ScrumMaster uses to track
                        > progress.
                        >

                        Okay, so are you saying that the team members don't need to have
                        access to the backlog, look at changes to it, filter for things
                        assigned to them (if indeed that is tracked), sort on priority,
                        etc...

                        >From my experience, a standup (which I've advocated and practiced
                        for many years) is a great opportunity to communicate at a high
                        level, identifying who needs to work on what and who needs to work
                        together that day (since there are interdependencies).

                        However, what gets allocated during standups is usually at that high
                        level. "Steve, you add support for creating a switch, including
                        automated tests that test it." The details of what it means to
                        create a switch are not communicated (otherwise the standups are a
                        lot longer than 15 minutes).

                        So is it correct to say that the backlog contains those high level
                        items (high level requirements)? If so, where does the assignee go
                        to get the details? Wouldn't it be nice to be able to use that high
                        level item itself as a portal to the details?

                        > To track the backlogs overall, an Excel spreadsheet is
                        surprisingly
                        > useful. One of the beauties of Scrum is that it only requires
                        > lightweight management tools!

                        Sure, I know that Excel spreadsheets are incredibly useful.
                        However, I really think that using them for requirements is
                        capturing them at the wrong level of granularity (i.e. one file for
                        a set of requirements).

                        Couldn't there also be a "lighweight" tool that manages the
                        requirements one per file? My experience with Excel is that it's
                        great for initial tasks but as "things" change (and they always do)
                        it's difficult to tell what exactly has changed.

                        What does a "lightweight" tool mean to you (and others in the group)?

                        Looking forward to your response(s).

                        Cheers

                        >
                        > --Rick



                        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/
                      • Marco Abis
                        ... When I developed a simple requirement management web tool for a customer of mine (following the Robertson s Volere Requirement Template) I extended a Wiki
                        Message 11 of 15 , Jun 28, 2003
                        • 0 Attachment
                          >It would be nice to have a product that could show me (in soft of a visual diff
                          >way) all the requirements that changed in priority, estimate, or are new.
                          >That's the type of thing that is a bit hard in Excel. (I do it in Excel by
                          >using a version control system, exporting spreadsheets to CSV files and then
                          >using WinMerge as a good visual differencing tool).

                          When I developed a simple requirement management web tool for a customer of mine (following the Robertson's Volere Requirement Template) I extended a Wiki because of the built-in version control feature. Every time someone changes a page (any page actually, not only requirements ones) the Wiki doesn't replace the page but creates a new version of it mantaining the history of that page/requirement.

                          As I already wrote some months ago I then started an open-source version of that web tool with PHP & MySQL (the original is now in .NET & SQL Server and is property of that customer) but I've never finished it. Maybe I can try to resurrect it to do what you wrote. :)



                          Marco Abis
                          Agility SPI: Software Process Improvement
                          abis@... - abis@...
                          http://agilemovement.it
                        • Mike Cohn
                          Hi Marco-- I ve always thought PHP/MySQL would be the right set of tools for a Scrum tracking tool. PHP is so easy to customize and change. I ve been amazed at
                          Message 12 of 15 , Jun 28, 2003
                          • 0 Attachment
                            Hi Marco--
                            I've always thought PHP/MySQL would be the right set of tools for a Scrum
                            tracking tool. PHP is so easy to customize and change. I've been amazed at
                            products like phpBB (for bulletin boards) and how easy it is to extend with
                            a completely new look and custom features. A Scrum tool like that seems like
                            it would be popular because teams could change it some to fit their
                            environments.

                            -Mike

                            -----Original Message-----
                            From: Marco Abis [mailto:abis@...]
                            Sent: Saturday, June 28, 2003 4:43 AM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: RE: [scrumdevelopment] Re: Managing the Scrum backlogs...


                            >It would be nice to have a product that could show me (in soft of a visual
                            diff
                            >way) all the requirements that changed in priority, estimate, or are new.
                            >That's the type of thing that is a bit hard in Excel. (I do it in Excel by
                            >using a version control system, exporting spreadsheets to CSV files and
                            then
                            >using WinMerge as a good visual differencing tool).

                            When I developed a simple requirement management web tool for a customer of
                            mine (following the Robertson's Volere Requirement Template) I extended a
                            Wiki because of the built-in version control feature. Every time someone
                            changes a page (any page actually, not only requirements ones) the Wiki
                            doesn't replace the page but creates a new version of it mantaining the
                            history of that page/requirement.

                            As I already wrote some months ago I then started an open-source version of
                            that web tool with PHP & MySQL (the original is now in .NET & SQL Server and
                            is property of that customer) but I've never finished it. Maybe I can try to
                            resurrect it to do what you wrote. :)



                            Marco Abis
                            Agility SPI: Software Process Improvement
                            abis@... - abis@...
                            http://agilemovement.it



                            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/
                          • JIM WIESEN
                            I m a little confused about how to handle product backlog tasks that are say 100 days in duration. If the team is supposed to pick items off of the product
                            Message 13 of 15 , Jun 30, 2003
                            • 0 Attachment
                              I'm a little confused about how to handle product backlog tasks that are say
                              100 days in duration. If the team is supposed to pick items off of the
                              product backlog to add into a sprint, how do we handle something like this?
                              We obviously can't complete a 100 day task in 30 days. Should the task be
                              broken down into sub-30 days items, or should we take the task as a whole
                              and add anything that is going to be unfinished back to the product backlog?


                              -----Original Message-----
                              From: Mike Cohn [mailto:mike@...]
                              Sent: Friday, June 27, 2003 9:42 PM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: RE: [scrumdevelopment] Re: Managing the Scrum backlogs...

                              First, you need to understand a couple of fundamental things about Scrum so
                              you can understand the rest:

                              a) Scrum requires self-organizing teams. So, there is no allocation of tasks
                              during meetings. No, "Steve, you add support for...". Instead, team members
                              sign up for tasks.

                              b) In general, team members sign up for a task the day they start it, not in
                              advance. So, there's no real need to "sort on priority" or search for
                              assigned tasks, etc. During a sprint planning meeting a team will typically,
                              to some extent, "pre-signup" for work so they can determine if they're
                              bringing the right amount of work into the sprint. But that changes day to
                              day (perhaps not really during the first week or so) as learning about the
                              tasks occurs.

                              c) As others and I have said there are two backlogs: product and sprint.
                              Product backlog items might be "high level items" but sprint backlog are
                              tasks (not requirements per se) and are rarely more than 16 hours. Product
                              backlog items may be huge--I'll routinely have some big product backlog
                              tasks that we can't assess well (and time isn't worth spending on such an
                              effort). Those may be in as 100 days, for example.

                              d) The person working on a task (definitely never an "assignee") goes to the
                              "Product Owner" to find out the requirements. A Scrum team could perhaps use
                              a document to reflect the requirements of a given sprint but they are
                              generally trying to move too quickly and will instead prefer verbal
                              communication, much as with any of the other agile processes.

                              As to a lightweight tool: I'm intrigued by the use of tools for this purpose
                              but not so much for the day to day tracking of work left on a task or within
                              a sprint. The real value would more likely be found in organizing product
                              backlog items into release plans and also into being able to look back at
                              those over time. For example, we'll often start what we know will be a
                              multi-month project with just enough requirements to do the first sprint
                              (month). During the first month the Product Owner loads up the Product
                              Backlog. After a month we may work with the PO and determine an approximate
                              place we'll get to by the 5th sprint, at which point we'll release. But,
                              then after 4 months we might still be two (instead of 1) sprint away. It
                              would be nice to have a product that could show me (in soft of a visual diff
                              way) all the requirements that changed in priority, estimate, or are new.
                              That's the type of thing that is a bit hard in Excel. (I do it in Excel by
                              using a version control system, exporting spreadsheets to CSV files and then
                              using WinMerge as a good visual differencing tool).

                              I hope that helps,

                              -Mike

                              -----Original Message-----
                              From: bannerma [mailto:steve.bannerman@...]
                              Sent: Friday, June 27, 2003 8:00 AM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: [scrumdevelopment] Re: Managing the Scrum backlogs...

                              Rick,

                              Thanks for your answers...replies below:

                              --- In scrumdevelopment@yahoogroups.com, Rick Innis <rick@i...>
                              wrote:
                              > .
                              > .
                              > .
                              >
                              > Again as I understand it, managing the backlog is part of the
                              > ScrumMaster's job. The daily scrum is an important part of
                              managing the
                              > backlogs because it's the mechanism the ScrumMaster uses to track
                              > progress.
                              >

                              Okay, so are you saying that the team members don't need to have
                              access to the backlog, look at changes to it, filter for things
                              assigned to them (if indeed that is tracked), sort on priority,
                              etc...

                              >From my experience, a standup (which I've advocated and practiced
                              for many years) is a great opportunity to communicate at a high
                              level, identifying who needs to work on what and who needs to work
                              together that day (since there are interdependencies).

                              However, what gets allocated during standups is usually at that high
                              level. "Steve, you add support for creating a switch, including
                              automated tests that test it." The details of what it means to
                              create a switch are not communicated (otherwise the standups are a
                              lot longer than 15 minutes).

                              So is it correct to say that the backlog contains those high level
                              items (high level requirements)? If so, where does the assignee go
                              to get the details? Wouldn't it be nice to be able to use that high
                              level item itself as a portal to the details?

                              > To track the backlogs overall, an Excel spreadsheet is
                              surprisingly
                              > useful. One of the beauties of Scrum is that it only requires
                              > lightweight management tools!

                              Sure, I know that Excel spreadsheets are incredibly useful.
                              However, I really think that using them for requirements is
                              capturing them at the wrong level of granularity (i.e. one file for
                              a set of requirements).

                              Couldn't there also be a "lighweight" tool that manages the
                              requirements one per file? My experience with Excel is that it's
                              great for initial tasks but as "things" change (and they always do)
                              it's difficult to tell what exactly has changed.

                              What does a "lightweight" tool mean to you (and others in the group)?

                              Looking forward to your response(s).

                              Cheers

                              >
                              > --Rick



                              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 http://docs.yahoo.com/info/terms/
                            • Ken Schwaber
                              As requirements rise in the priority of the product backlog, they are usually thought through more. As they are thought through more, they become more
                              Message 14 of 15 , Jun 30, 2003
                              • 0 Attachment
                                As requirements rise in the priority of the product backlog, they are
                                usually thought through more. As they are thought through more, they become
                                more granular. High priority product backlog rarely are more than 10 days.
                                If a high priority product backlog is 100 days, think it through more and
                                break it down. If it is low priority, then 100 days is not rare.
                                Ken

                                -----Original Message-----
                                From: JIM WIESEN [mailto:jwiesen@...]
                                Sent: Monday, June 30, 2003 10:51 AM
                                To: 'scrumdevelopment@yahoogroups.com'
                                Subject: RE: [scrumdevelopment] Re: Managing the Scrum backlogs...


                                I'm a little confused about how to handle product backlog tasks that are say
                                100 days in duration. If the team is supposed to pick items off of the
                                product backlog to add into a sprint, how do we handle something like this?
                                We obviously can't complete a 100 day task in 30 days. Should the task be
                                broken down into sub-30 days items, or should we take the task as a whole
                                and add anything that is going to be unfinished back to the product backlog?


                                -----Original Message-----
                                From: Mike Cohn [mailto:mike@...]
                                Sent: Friday, June 27, 2003 9:42 PM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] Re: Managing the Scrum backlogs...

                                First, you need to understand a couple of fundamental things about Scrum so
                                you can understand the rest:

                                a) Scrum requires self-organizing teams. So, there is no allocation of tasks
                                during meetings. No, "Steve, you add support for...". Instead, team members
                                sign up for tasks.

                                b) In general, team members sign up for a task the day they start it, not in
                                advance. So, there's no real need to "sort on priority" or search for
                                assigned tasks, etc. During a sprint planning meeting a team will typically,
                                to some extent, "pre-signup" for work so they can determine if they're
                                bringing the right amount of work into the sprint. But that changes day to
                                day (perhaps not really during the first week or so) as learning about the
                                tasks occurs.

                                c) As others and I have said there are two backlogs: product and sprint.
                                Product backlog items might be "high level items" but sprint backlog are
                                tasks (not requirements per se) and are rarely more than 16 hours. Product
                                backlog items may be huge--I'll routinely have some big product backlog
                                tasks that we can't assess well (and time isn't worth spending on such an
                                effort). Those may be in as 100 days, for example.

                                d) The person working on a task (definitely never an "assignee") goes to the
                                "Product Owner" to find out the requirements. A Scrum team could perhaps use
                                a document to reflect the requirements of a given sprint but they are
                                generally trying to move too quickly and will instead prefer verbal
                                communication, much as with any of the other agile processes.

                                As to a lightweight tool: I'm intrigued by the use of tools for this purpose
                                but not so much for the day to day tracking of work left on a task or within
                                a sprint. The real value would more likely be found in organizing product
                                backlog items into release plans and also into being able to look back at
                                those over time. For example, we'll often start what we know will be a
                                multi-month project with just enough requirements to do the first sprint
                                (month). During the first month the Product Owner loads up the Product
                                Backlog. After a month we may work with the PO and determine an approximate
                                place we'll get to by the 5th sprint, at which point we'll release. But,
                                then after 4 months we might still be two (instead of 1) sprint away. It
                                would be nice to have a product that could show me (in soft of a visual diff
                                way) all the requirements that changed in priority, estimate, or are new.
                                That's the type of thing that is a bit hard in Excel. (I do it in Excel by
                                using a version control system, exporting spreadsheets to CSV files and then
                                using WinMerge as a good visual differencing tool).

                                I hope that helps,

                                -Mike

                                -----Original Message-----
                                From: bannerma [mailto:steve.bannerman@...]
                                Sent: Friday, June 27, 2003 8:00 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: [scrumdevelopment] Re: Managing the Scrum backlogs...

                                Rick,

                                Thanks for your answers...replies below:

                                --- In scrumdevelopment@yahoogroups.com, Rick Innis <rick@i...>
                                wrote:
                                > .
                                > .
                                > .
                                >
                                > Again as I understand it, managing the backlog is part of the
                                > ScrumMaster's job. The daily scrum is an important part of
                                managing the
                                > backlogs because it's the mechanism the ScrumMaster uses to track
                                > progress.
                                >

                                Okay, so are you saying that the team members don't need to have
                                access to the backlog, look at changes to it, filter for things
                                assigned to them (if indeed that is tracked), sort on priority,
                                etc...

                                >From my experience, a standup (which I've advocated and practiced
                                for many years) is a great opportunity to communicate at a high
                                level, identifying who needs to work on what and who needs to work
                                together that day (since there are interdependencies).

                                However, what gets allocated during standups is usually at that high
                                level. "Steve, you add support for creating a switch, including
                                automated tests that test it." The details of what it means to
                                create a switch are not communicated (otherwise the standups are a
                                lot longer than 15 minutes).

                                So is it correct to say that the backlog contains those high level
                                items (high level requirements)? If so, where does the assignee go
                                to get the details? Wouldn't it be nice to be able to use that high
                                level item itself as a portal to the details?

                                > To track the backlogs overall, an Excel spreadsheet is
                                surprisingly
                                > useful. One of the beauties of Scrum is that it only requires
                                > lightweight management tools!

                                Sure, I know that Excel spreadsheets are incredibly useful.
                                However, I really think that using them for requirements is
                                capturing them at the wrong level of granularity (i.e. one file for
                                a set of requirements).

                                Couldn't there also be a "lighweight" tool that manages the
                                requirements one per file? My experience with Excel is that it's
                                great for initial tasks but as "things" change (and they always do)
                                it's difficult to tell what exactly has changed.

                                What does a "lightweight" tool mean to you (and others in the group)?

                                Looking forward to your response(s).

                                Cheers

                                >
                                > --Rick



                                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 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 http://docs.yahoo.com/info/terms/
                              • Mike Cohn
                                Exactly. We don t bother thinking much about distant requirements until we know they are either going into this sprint or will *definitely* go into a release
                                Message 15 of 15 , Jun 30, 2003
                                • 0 Attachment
                                  Exactly. We don't bother thinking much about distant requirements until we
                                  know they are either going into this sprint or will *definitely* go into a
                                  release (even if perhaps 3 sprints out).

                                  -Mike

                                  -----Original Message-----
                                  From: Ken Schwaber [mailto:ken.schwaber@...]
                                  Sent: Monday, June 30, 2003 9:08 AM
                                  To: scrumdevelopment@yahoogroups.com
                                  Subject: RE: [scrumdevelopment] Re: Managing the Scrum backlogs...

                                  As requirements rise in the priority of the product backlog, they are
                                  usually thought through more. As they are thought through more, they become
                                  more granular. High priority product backlog rarely are more than 10 days.
                                  If a high priority product backlog is 100 days, think it through more and
                                  break it down. If it is low priority, then 100 days is not rare.
                                  Ken

                                  -----Original Message-----
                                  From: JIM WIESEN [mailto:jwiesen@...]
                                  Sent: Monday, June 30, 2003 10:51 AM
                                  To: 'scrumdevelopment@yahoogroups.com'
                                  Subject: RE: [scrumdevelopment] Re: Managing the Scrum backlogs...


                                  I'm a little confused about how to handle product backlog tasks that are say
                                  100 days in duration. If the team is supposed to pick items off of the
                                  product backlog to add into a sprint, how do we handle something like this?
                                  We obviously can't complete a 100 day task in 30 days. Should the task be
                                  broken down into sub-30 days items, or should we take the task as a whole
                                  and add anything that is going to be unfinished back to the product backlog?


                                  -----Original Message-----
                                  From: Mike Cohn [mailto:mike@...]
                                  Sent: Friday, June 27, 2003 9:42 PM
                                  To: scrumdevelopment@yahoogroups.com
                                  Subject: RE: [scrumdevelopment] Re: Managing the Scrum backlogs...

                                  First, you need to understand a couple of fundamental things about Scrum so
                                  you can understand the rest:

                                  a) Scrum requires self-organizing teams. So, there is no allocation of tasks
                                  during meetings. No, "Steve, you add support for...". Instead, team members
                                  sign up for tasks.

                                  b) In general, team members sign up for a task the day they start it, not in
                                  advance. So, there's no real need to "sort on priority" or search for
                                  assigned tasks, etc. During a sprint planning meeting a team will typically,
                                  to some extent, "pre-signup" for work so they can determine if they're
                                  bringing the right amount of work into the sprint. But that changes day to
                                  day (perhaps not really during the first week or so) as learning about the
                                  tasks occurs.

                                  c) As others and I have said there are two backlogs: product and sprint.
                                  Product backlog items might be "high level items" but sprint backlog are
                                  tasks (not requirements per se) and are rarely more than 16 hours. Product
                                  backlog items may be huge--I'll routinely have some big product backlog
                                  tasks that we can't assess well (and time isn't worth spending on such an
                                  effort). Those may be in as 100 days, for example.

                                  d) The person working on a task (definitely never an "assignee") goes to the
                                  "Product Owner" to find out the requirements. A Scrum team could perhaps use
                                  a document to reflect the requirements of a given sprint but they are
                                  generally trying to move too quickly and will instead prefer verbal
                                  communication, much as with any of the other agile processes.

                                  As to a lightweight tool: I'm intrigued by the use of tools for this purpose
                                  but not so much for the day to day tracking of work left on a task or within
                                  a sprint. The real value would more likely be found in organizing product
                                  backlog items into release plans and also into being able to look back at
                                  those over time. For example, we'll often start what we know will be a
                                  multi-month project with just enough requirements to do the first sprint
                                  (month). During the first month the Product Owner loads up the Product
                                  Backlog. After a month we may work with the PO and determine an approximate
                                  place we'll get to by the 5th sprint, at which point we'll release. But,
                                  then after 4 months we might still be two (instead of 1) sprint away. It
                                  would be nice to have a product that could show me (in soft of a visual diff
                                  way) all the requirements that changed in priority, estimate, or are new.
                                  That's the type of thing that is a bit hard in Excel. (I do it in Excel by
                                  using a version control system, exporting spreadsheets to CSV files and then
                                  using WinMerge as a good visual differencing tool).

                                  I hope that helps,

                                  -Mike

                                  -----Original Message-----
                                  From: bannerma [mailto:steve.bannerman@...]
                                  Sent: Friday, June 27, 2003 8:00 AM
                                  To: scrumdevelopment@yahoogroups.com
                                  Subject: [scrumdevelopment] Re: Managing the Scrum backlogs...

                                  Rick,

                                  Thanks for your answers...replies below:

                                  --- In scrumdevelopment@yahoogroups.com, Rick Innis <rick@i...>
                                  wrote:
                                  > .
                                  > .
                                  > .
                                  >
                                  > Again as I understand it, managing the backlog is part of the
                                  > ScrumMaster's job. The daily scrum is an important part of
                                  managing the
                                  > backlogs because it's the mechanism the ScrumMaster uses to track
                                  > progress.
                                  >

                                  Okay, so are you saying that the team members don't need to have
                                  access to the backlog, look at changes to it, filter for things
                                  assigned to them (if indeed that is tracked), sort on priority,
                                  etc...

                                  >From my experience, a standup (which I've advocated and practiced
                                  for many years) is a great opportunity to communicate at a high
                                  level, identifying who needs to work on what and who needs to work
                                  together that day (since there are interdependencies).

                                  However, what gets allocated during standups is usually at that high
                                  level. "Steve, you add support for creating a switch, including
                                  automated tests that test it." The details of what it means to
                                  create a switch are not communicated (otherwise the standups are a
                                  lot longer than 15 minutes).

                                  So is it correct to say that the backlog contains those high level
                                  items (high level requirements)? If so, where does the assignee go
                                  to get the details? Wouldn't it be nice to be able to use that high
                                  level item itself as a portal to the details?

                                  > To track the backlogs overall, an Excel spreadsheet is
                                  surprisingly
                                  > useful. One of the beauties of Scrum is that it only requires
                                  > lightweight management tools!

                                  Sure, I know that Excel spreadsheets are incredibly useful.
                                  However, I really think that using them for requirements is
                                  capturing them at the wrong level of granularity (i.e. one file for
                                  a set of requirements).

                                  Couldn't there also be a "lighweight" tool that manages the
                                  requirements one per file? My experience with Excel is that it's
                                  great for initial tasks but as "things" change (and they always do)
                                  it's difficult to tell what exactly has changed.

                                  What does a "lightweight" tool mean to you (and others in the group)?

                                  Looking forward to your response(s).

                                  Cheers

                                  >
                                  > --Rick



                                  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 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 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 http://docs.yahoo.com/info/terms/
                                Your message has been successfully submitted and would be delivered to recipients shortly.