24270Re: [scrumdevelopment] Product backlog issues
- Oct 4, 2007My 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.
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
- << Previous post in topic Next post in topic >>