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

24267Product backlog issues

Expand Messages
  • Vincent, Peter
    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/
    • Show all 5 messages in this topic