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

Product backlog issues

Expand Messages
  • Vincent, Peter
    We have been running SCRUM for 6 months in small projects, we are pleased with the result and are now in for scaling it up to a bigger project. We have a fixed
    Message 1 of 5 , Oct 4, 2007
      We have been running SCRUM for 6 months in small projects, we are pleased with the result and are now in for scaling it up to a bigger project. We have a fixed price project estimated to 30 000 hours. The plan is to have 30 persons working on the project for 6 months. After the initial stirr of getting a contract and then extracting some basic requirements, we have been able to nail down 30 functions that are new functions requested by the customer and the new technology that is needed to fulfill this. Each "item" in the backlog is rather big, the span is from 20 - 100 man days.
       
      The system we are building on is a distributed system with a lot of complexity, since there are transactions in the system that never should fail. We have 6 subsystems, interconnected to each other in various way. Previously, we have been organized dependent on each subsystem, which has forced us to work hard on how to integrate the different parts with each other. This has pushed us in a direction, where a lot of time is spent on the acutal integration, and sometimes is a diffficult part since everybody has to be ready with their parts before full integration can be achieved.
       
      In the initial phase, we have tried to form some strategy around this, but we are still adding more questions than answers:
       
      * Vertical or horizontal teams - pros and cons? We have had planning sessions where we try to create scrum teams based on functionality, independent of which subsystem they have their most knowledge. All attempts has ended with one team being very heavy with all experts, and the others not well balanced.
       
      * Splitting of backlog items - What is the prefered size of an item? How do we split parts which involves all subsystem for final solution of the function (depending on the answer above, it migth be natural...)? Is it a good thing to split an item and have very litttle expectations on the first sprint to proof test the design (i.e focus on system design, only implemeting the easiest story, and not focus on deliverable functionality?)
       
      * Regression test - We are in a situation where we initially wants a lot of manpower for regression test, and to do the same at the end. Initially, we want to test that all functions are working before we start changing things, and then we want to test before delivery that everything works together. First gut feeling is to make 1 or two scrum teams responsible for this consisting of 4 developers and 3 testers. When the regression test is done, scrum teams are reconfigured... We have a lot of automatic test suites, but since we are deploying on hardware that needs physical interaction to work (i.e bill readers), we can not to system test without people. Any thougths?
       
      All input at this stage is welcome!
       
      Peter Vincent 
       
      ###########################################

      This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
      For more information, connect to http://www.f-secure.com/
    • George Dinwiddie
      ... I will always choose vertical teams. I think that the functionality tends to find the appropriate place in the design when working that way. There s also
      Message 2 of 5 , Oct 4, 2007
        On Thu, October 4, 2007 16:04, Vincent, Peter wrote:
        > In the initial phase, we have tried to form some strategy around this,
        > but we are still adding more questions than answers:
        >
        > * Vertical or horizontal teams - pros and cons? We have had planning
        > sessions where we try to create scrum teams based on functionality,
        > independent of which subsystem they have their most knowledge. All
        > attempts has ended with one team being very heavy with all experts, and
        > the others not well balanced.

        I will always choose vertical teams. I think that the functionality tends
        to find the appropriate place in the design when working that way.
        There's also less hand-off of information about the functionality and the
        choices made.

        You may want to shuffle the experts so they're more evenly distributed.
        The experts can be the ones who participate in a scrum of scrums to keep
        all the parts in sync.

        > * Splitting of backlog items - What is the prefered size of an item? How
        > do we split parts which involves all subsystem for final solution of the
        > function (depending on the answer above, it migth be natural...)? Is it
        > a good thing to split an item and have very litttle expectations on the
        > first sprint to proof test the design (i.e focus on system design, only
        > implemeting the easiest story, and not focus on deliverable
        > functionality?)

        Size? As small as possible, in my experience. Again, I recommend
        splitting vertically rather than horizontally. See
        http://xp123.com/xplor/xp0512/index.shtml for William Wake's "Twenty Ways
        to Split Stories."

        > * Regression test - We are in a situation where we initially wants a lot
        > of manpower for regression test, and to do the same at the end.
        > Initially, we want to test that all functions are working before we
        > start changing things, and then we want to test before delivery that
        > everything works together. First gut feeling is to make 1 or two scrum
        > teams responsible for this consisting of 4 developers and 3 testers.
        > When the regression test is done, scrum teams are reconfigured... We
        > have a lot of automatic test suites, but since we are deploying on
        > hardware that needs physical interaction to work (i.e bill readers), we
        > can not to system test without people. Any thougths?

        I suggest automating as much as possible--to the extent of mocking out the
        physical hardware for most tests. You might consider getting all of the
        teams working on building the initial characterization tests in order to
        build them as quickly as possible.

        - George


        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Ramon Davila
        ... Vertical teams are able to deliver working software at the end of every iteration. This arrangement forces the teams to develop the expertise required to
        Message 3 of 5 , Oct 4, 2007
          On 10/4/07, Vincent, Peter <peter.vincent@...> wrote:
          >
          >
          >
          >
          >
          >
          >
          > We have been running SCRUM for 6 months in small projects, we are pleased with the result and are now in for scaling it up to a bigger project. We have a fixed price project estimated to 30 000 hours. The plan is to have 30 persons working on the project for 6 months. After the initial stirr of getting a contract and then extracting some basic requirements, we have been able to nail down 30 functions that are new functions requested by the customer and the new technology that is needed to fulfill this. Each "item" in the backlog is rather big, the span is from 20 - 100 man days.
          >
          > The system we are building on is a distributed system with a lot of complexity, since there are transactions in the system that never should fail. We have 6 subsystems, interconnected to each other in various way. Previously, we have been organized dependent on each subsystem, which has forced us to work hard on how to integrate the different parts with each other. This has pushed us in a direction, where a lot of time is spent on the acutal integration, and sometimes is a diffficult part since everybody has to be ready with their parts before full integration can be achieved.
          >
          > In the initial phase, we have tried to form some strategy around this, but we are still adding more questions than answers:
          >
          > * Vertical or horizontal teams - pros and cons? We have had planning sessions where we try to create scrum teams based on functionality, independent of which subsystem they have their most knowledge. All attempts has ended with one team being very heavy with all experts, and the others not well balanced.
          >
          Vertical teams are able to deliver working software at the end of
          every iteration. This arrangement forces the teams to develop the
          expertise required to work on multiple layers of the application. In
          my experience horizontal teams to create communication and
          synchronization overhead, and favor the tendency to develop a few
          experts on certain parts of the system who in turn my become
          bottlenecks. Another issue to consider is that is harder to deliver
          full working features at the end of every iteration when a team is not
          fully empowered to complete those features

          > * Splitting of backlog items - What is the preferred size of an item? How do we split parts which involves all subsystem for final solution of the function (depending on the answer above, it might be natural...)? Is it a good thing to split an item and have very little expectations on the first sprint to proof test the design (i.e focus on system design, only implementing the easiest story, and not focus on deliverable functionality?)
          >

          Product backlog items may be of different sizes, depending on how much
          you know about them and some other factors. I prefer sprint backlog
          items to be small enough for a pair to finish in a couple of days so
          a big product backlog items may need to be split before the team picks
          it up for a given sprint.

          > * Regression test - We are in a situation where we initially wants a lot of manpower for regression test, and to do the same at the end. Initially, we want to test that all functions are working before we start changing things, and then we want to test before delivery that everything works together. First gut feeling is to make 1 or two scrum teams responsible for this consisting of 4 developers and 3 testers. When the regression test is done, scrum teams are reconfigured... We have a lot of automatic test suites, but since we are deploying on hardware that needs physical interaction to work (i.e bill readers), we can not to system test without people. Any thougths?
          >
          You should strive to automate as much as possible. one option is to
          have stubs for the externals systems, so that you can continuously
          execute tests against them. That will minimize surprises at the time
          you manually test against the real systems


          > All input at this stage is welcome!
          >
          > Peter Vincent
          > ###########################################
          >
          > This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
          > For more information, connect to http://www.f-secure.com/
          >
          >
        • Malcolm Anderson
          My standard go to suggestion is to spend some time on Continuous Integration. Add to that a wire frame version of your architecture and have you BA s start
          Message 4 of 5 , Oct 4, 2007
            My standard "go to" suggestion is to spend some time on Continuous Integration.

            Add to that a wire frame version of your architecture and have you
            BA's start working with Devs and QA to come up with good functional
            tests for each process and end state in the system. That way you can
            start in a fully integrated state, and "stop the line" whenever it
            breaks. By mocking out the portions that are not currently working,
            you can stay in a state of constant verified integration.

            It's much cheaper to stay in an integrated state, than it is to wedge
            things together when it's all done.

            This way, your developers can keep themselves present to the interface
            that they are working inside of.

            Do you have any people on the team with strong eXtreme Programming
            (XP) experience? TDD and CI can save your sanity.

            Malcolm


            On 10/4/07, Vincent, Peter <peter.vincent@...> wrote:
            > We have been running SCRUM for 6 months in small projects, we are pleased with the result and are now in for scaling it up to a bigger project. We have a fixed price project estimated to 30 000 hours. The plan is to have 30 persons working on the project for 6 months. After the initial stirr of getting a contract and then extracting some basic requirements, we have been able to nail down 30 functions that are new functions requested by the customer and the new technology that is needed to fulfill this. Each "item" in the backlog is rather big, the span is from 20 - 100 man days.
            >
            > The system we are building on is a distributed system with a lot of complexity, since there are transactions in the system that never should fail. We have 6 subsystems, interconnected to each other in various way. Previously, we have been organized dependent on each subsystem, which has forced us to work hard on how to integrate the different parts with each other. This has pushed us in a direction, where a lot of time is spent on the acutal integration, and sometimes is a diffficult part since everybody has to be ready with their parts before full integration can be achieved.
            >
            > In the initial phase, we have tried to form some strategy around this, but we are still adding more questions than answers:
            >
            > * Vertical or horizontal teams - pros and cons? We have had planning sessions where we try to create scrum teams based on functionality, independent of which subsystem they have their most knowledge. All attempts has ended with one team being very heavy with all experts, and the others not well balanced.
            >
            > * Splitting of backlog items - What is the prefered size of an item? How do we split parts which involves all subsystem for final solution of the function (depending on the answer above, it migth be natural...)? Is it a good thing to split an item and have very litttle expectations on the first sprint to proof test the design (i.e focus on system design, only implemeting the easiest story, and not focus on deliverable functionality?)
            >
            > * Regression test - We are in a situation where we initially wants a lot of manpower for regression test, and to do the same at the end. Initially, we want to test that all functions are working before we start changing things, and then we want to test before delivery that everything works together. First gut feeling is to make 1 or two scrum teams responsible for this consisting of 4 developers and 3 testers. When the regression test is done, scrum teams are reconfigured... We have a lot of automatic test suites, but since we are deploying on hardware that needs physical interaction to work (i.e bill readers), we can not to system test without people. Any thougths?
            >
            > All input at this stage is welcome!
            >
            > Peter Vincent
          • Roy Morien
            I am interested in the concepts of vertical splitting versus horizontal splitting . This reminds me of the discussions years ago about types of software
            Message 5 of 5 , Oct 4, 2007
              I am interested in the concepts of 'vertical splitting' versus 'horizontal splitting'. This reminds me of the discussions years ago about types of software prototyping, where the same terms were used 'vertical prototyping' versus 'horizontal prototyping'.
               
              Horizontal prototyping was basically creating a visual interface .. the intention was to create the visual front end to allow a user to step through the 'whole' system and experience what it looked like, and how it would be operated. It was a bit like a western movie film set where 'main street' was a lot of mockup shop front facades with nothing behind it.
               
              In 1992 I published a paper about what I called Focal Entity Prototyping. This is very much a vertical splitting approach, fundamentally based on a development cycle of < Entity Identification and Definition => Transform to Table Definition ==> Construct Table ==> Develop basic processing (Add, Delete, Modify, Search, Sequence, Lookup etc) and some basic reports and DB triggers and Stored Procedures based on that Table.
               
              This vertical splitting, or focussing on a small component is very effective and very efficient. One benefit of this is that it does not dissipate your attention and concentration; sort of juggling one ball instead of 6.
               
              Clearly this can be done provided you understand and adopt the principles of 'coupling' and 'cohesion'. Coupling, of course, is some measure of the dependancy and association between components. Low coupling is desirable and should be your clear intention. Cohesion is the the measure of how introspective the functionality of any given component is ... sort of 'the component, all about the component, nothing but the component'.
               
              I sometimes wonder when problems are stated here about distributed teams, distributed development etc. how much the difficulties are created by having too highly coupled components or aspects of the system, and too little cohesion.

              Regards,
              Roy Morien



              To: scrumdevelopment@yahoogroups.com
              From: lists@...
              Date: Thu, 4 Oct 2007 17:05:40 -0400
              Subject: Re: [scrumdevelopment] Product backlog issues


              On Thu, October 4, 2007 16:04, Vincent, Peter wrote:
              > In the initial phase, we have tried to form some strategy around this,
              > but we are still adding more questions than answers:
              >
              > * Vertical or horizontal teams - pros and cons? We have had planning
              > sessions where we try to create scrum teams based on functionality,
              > independent of which subsystem they have their most knowledge. All
              > attempts has ended with one team being very heavy with all experts, and
              > the others not well balanced.

              I will always choose vertical teams. I think that the functionality tends
              to find the appropriate place in the design when working that way.
              There's also less hand-off of information about the functionality and the
              choices made.

              You may want to shuffle the experts so they're more evenly distributed.
              The experts can be the ones who participate in a scrum of scrums to keep
              all the parts in sync.

              > * Splitting of backlog items - What is the prefered size of an item? How
              > do we split parts which involves all subsystem for final solution of the
              > function (depending on the answer above, it migth be natural...)? Is it
              > a good thing to split an item and have very litttle expectations on the
              > first sprint to proof test the design (i.e focus on system design, only
              > implemeting the easiest story, and not focus on deliverable
              > functionality? )

              Size? As small as possible, in my experience. Again, I recommend
              splitting vertically rather than horizontally. See
              http://xp123. com/xplor/ xp0512/index. shtml for William Wake's "Twenty Ways
              to Split Stories."

              > * Regression test - We are in a situation where we initially wants a lot
              > of manpower for regression test, and to do the same at the end.
              > Initially, we want to test that all functions are working before we
              > start changing things, and then we want to test before delivery that
              > everything works together. First gut feeling is to make 1 or two scrum
              > teams responsible for this consisting of 4 developers and 3 testers.
              > When the regression test is done, scrum teams are reconfigured. .. We
              > have a lot of automatic test suites, but since we are deploying on
              > hardware that needs physical interaction to work (i.e bill readers), we
              > can not to system test without people. Any thougths?

              I suggest automating as much as possible--to the extent of mocking out the
              physical hardware for most tests. You might consider getting all of the
              teams working on building the initial characterization tests in order to
              build them as quickly as possible.

              - George

              --
              ------------ --------- --------- --------- --------- --------- -
              * George Dinwiddie * http://blog. gdinwiddie. com
              Software Development http://www.idiacomp uting.com
              Consultant and Coach http://www.agilemar yland.org
              ------------ --------- --------- --------- --------- --------- -




              Enter here. Win tix to see Crowded House live at the Greek Theatre, LA!
            Your message has been successfully submitted and would be delivered to recipients shortly.