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

24269Re: [scrumdevelopment] Product backlog issues

Expand Messages
  • Ramon Davila
    Oct 4, 2007
    • 0 Attachment
      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/
      >
      >
    • Show all 5 messages in this topic