How to organize sprints during the user acceptance tests phase?

Question

What is the suggested approach to sprints organization during the tests phase? Lets assume that we have finished development sprints, internal tests (analysts & developers) are over. Application is deployed on test environment for user acceptance tests. Those tests are covered by business users of the application.

What should we do now?

1. Do something else waiting for users bugs for the next sprint?
2. Plan the sprint for period of time without any issues and solve the bugs as they come?
3. Start the next sprint, what to do with bugs that are coming?

Answer 1

In the ideal situation you should deploy new version after each sprint when you were building application so testing phase would be spread over the longer period of time.

Having said that I understand there are clients who expect acceptance testing phase done at the end, after delivery of the whole functionality.

For this situation I consider fixing bugs has higher priority than developing new features. You have a few options here:

1. Start a new sprint, plan for smaller velocity than typical. For the first sprint you can follow you gut feeling to set expected velocity. Then you fix bugs as they come which affects negatively how much new work you can do. This way you should be able to fix bugs and do some new work. However you risk a lot of context switching, as people will drop working on new tasks to fix old bugs.

2. Start a new sprint but take away the part of the team as maintenance team for the old project. This way you have a standard sprint, although with smaller group of people, and a few others who should deal with submitted bugs. You can adjust the number of people in both groups after each sprint, depending on bug-related workload. Velocity of the team working on new features will be floating but you limit context-switching. However you risk frustration of people dealing with bugs as they'll be dealing with bugs made by themselves and those made by others, who currently work on new cool tasks. It's a good idea to mix people among those teams after each sprint if possible.

3. Set bug-fixing happy hours/days - time of day/week when everyone is dealing with bugs. Other than that they're building new features. You can adjust length of happy hours to amount of work you have with bug fixing. Again, you risk here that people will be fixing code authored by others, especially when someone build pretty low-quality code with a lot of bugs. However it introduce one for all, all for one kind of attitude in the team which usually works fine.

4. If there's enough bug fixing to fill all days for the whole team I'd wait with launching new sprint until there's at least someone who can deal with new tasks, no matter which method you choose.

Answer 2

In the environment you're describing, the ideal way would be to deliver the functionality in small increments. Every sprint should introduce new functionality or enhanced functionality for the users to test.

You should not wait until the whole development phase is over and only then start the user testing. It kind of missing the point of iterative development.

In the company I'm working for, we have development teams (also responsible for the functional testing) and then we have a solution testing team. The development teams deliver content in sprints. The solution level testing team has subsequent sprints in which they test the new features.

This way you can get feedback from the users in an early stage, in which you can still make changes and focus on the most important features.

Answer 3

If you're doing Scrum, you would do the testing during the Sprint where the development occurred. Feature is developed, feature is tested, both are accounted for in the Sprint plan -- the feature isn't "done" until it's been both developed and tested.

If you can't complete the testing in the same Sprint, you probably aren't breaking down your stories into small enough chunks. Worst case, test each story in the Sprint immediately after they are developed.

If you have a development "phase" (X number of Sprints), and a testing "phase", (Y number of Sprints), that's Waterfall (or iterative waterfall).

Answer 4

I have been involved in user acceptance testing while using scrum. Our UAT cycles were defined by contract and outside our span of control. We usually had 3 days of UAT followed by 2 of days for bug fixes, each product release would have at least three of these UAT cycles.

So our team broke the entire UAT period - about two weeks into several mini-sprints. Not strictly in the scrum framework but that's the beauty of scrum, you can and should adapt it to your environment. When the customer had the product and environment locked up for testing we would code bug fixes. When the environment was released back to us for bug fixes we would deploy the bug fixes from the prior bug fix mini-sprint and perform environmental testing.

We found that we usually had some spare cycles during UAT if we had done our jobs well and there were not a lot of bugs. We used this time for any neglected housekeeping tasks.