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?

  • Would it be a possibility to give the client regular previews of the work completed so far that they can critique but don't have to sign off on? It wouldn't be a full UAT, but it can give you an indication if you are taking things in the right direction. Commented Jun 15, 2019 at 8:32
  • @BartvanIngenSchenau unfortunately not. I agree with this approach, but I can't get the customer involved yet. Commented Jun 15, 2019 at 19:09

1 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.

  • It is worth noting that agile and scrum are much broader than having sprints, so my answer is focused on testing in iterations, not on the "right way" to practice scrum or be more agile.
    – Daniel
    Commented Jun 14, 2019 at 21:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.