The risk or cost of rolling out a release to the whole user group is large.
Identify a small group of users that can be used as pilot users. As few as 6-8 users can be representative for a whole user group. Deploy a release to production but only allow the selected users have access to it. Make sure that these users actually use the release in their day to day work.
The MRP has to include just enough functionality so that the selected users can perform meaningful work. By limiting the number of users you gain many advantages:
- Reduced MRP
It is easier to get acceptance for limiting functionality in the MRP if only a few users will be affected. The MRP can focus on main stream features and ignore special cases. The easiest way to cut the number of features that will be in demand is to use the User set by user set pattern.
- More manual processing
A limited release can depend upon manual processing to a much higher degree than if there were many users. When deciding on which features to include in the release you should check if it would be acceptable to depend on a manual procedure until a later release.
- Real usage data
It is often impossible to predict how much load a system will have to handle and which bottlenecks will be greatest. By studying real usage patterns from a limited release one can gain a much more precise understanding of how a system will scale.
- Less turbulence
Issues that are identified by the pilot users will not be as critical since they affect a small number of users. This makes it easier for the project to keep momentum towards the next release.
One prerequisite for a limited release is that it is possible to discern whether the system will be able to handle a particular task before work is started on it. Users will be very frustrated if they get halfway through a task and then realize that it cannot be completed. In a Replacement project or Enhancement project this problem can be mitigated by using the Facilitate switching pattern.
To count as a limited release the users must be performing real tasks within a particular workflow or set of operations. Sometimes the distinction between real tasks and testing can get blurred. Suppose you are developing a computer game and send an early version to a couple of avid gamers. Is that a limited release? The answer depends on how these users perceive what they are doing. You have a limited release if the gamers are playing the game because they like it. It is not a limited release if their motivation is to test the game in order to give you feedback.
There are innumerable ways to choose users for a limited release:
- Small user set
Is some cases the easiest strategy is to identify a small user set and deploy to that group. The advantage of this approach is that it is easy to inform these users about the release and to follow up any problems. The disadvantage is that other user groups may want to interact with the release in ways that differ from the chosen user set.
- Pilot users
Some projects recruit pilot users from one or more large user sets.
- Random users
Some web-applications have started to use a strategy whereby a limited number of users are chosen at random. These users may or may not be informed before being upgraded to the new release.
A release of a system that is going to be deployed to many branch offices should be deployed to just one or two offices first. The next release should then fix issues that have been identified by the first deployment. This second release can then be deployed to a larger number of offices.
Many web-applications now choose to roll out new features to a limited group of users. In some cases these users have previously agreed to being pilot users, in other cases pilot users are chosen at random.