Skip to content

Limited releases

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. The MDE has to include just enough functionality so that these users can perform meaningful work. By limiting the number of users you gain two advantages:

  • Reduced MDE
    It is easier to get acceptance for limiting functionality in the MDE if only a few users will be affected. Since only a few users will be using the release, the MDE can focus on main stream features and ignore special cases.

  • Less turbulence after release
    Issues that are identified by the pilot users will not be as critical since they affect a small number of users

One prerequisite for a limited release is that it is possible to discern whether the system will be able to handle a task before work is started. 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 principle.

The difference between limited releases and testing

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.