An agile approach with a waterfall delivery and the QA impact

Question

My customer signed off on a major enhancement to an existing application. The enhancement will be delivered as a single new release and I can't change this. However, how we get to this final release is in my control and I'm thinking we could still benefit from a sprint model.

My goal is to break down this large chunk of work into smaller user stories / tasks and hold sprints as we work towards the release, which is several months from now. My team is familiar with agile methodologies, and I think it will help us define the work, split it up across our team, build momentum, etc.

The area that is not clear to me is when to test. Normally, we would fully QA each item within the sprint, but with so many changes going into the application and the absence of UAT until all the work is done I'm not comfortable relying on testing that was done months earlier before handing it off to the customer.

Does anyone have experience with a similar approach? When is it best to test? Should I keep a traditional waterfall testing phase, test within the sprints, or is there a hybrid approach that is suitable?

Answer 1

The sprint timebox offers you iterations, which are a convenient pace-setting mechanism. For your question, we want to look at the idea of adding incremental development into the process. In incremental development, you complete fully-functioning and potentially shippable increments of the product regularly. You combine these together and you should have a potentially skippable product each sprint.

The benefit to this even in a waterfall environment is that you have a much better idea of what is and isn't complete. In a phase-gate approach, you don't know if anything is complete until the final stage sign-off. If this is a benefit you want to get, you have to do testing inside of the iteration, not in a later phase.