View Source

{alias:Pain}Regardless of how you plan to tackle [MRP] in a project, the first rule for an optimal [MRP] is that *pain is preferable to a long release*. Only include functionality that is absolutely essential. Features that are valuable but not essential should not be in a release that is more than [three months|release length] long. The hard part is getting stake holders to accept a painful release. This is especially true for functionality directed towards customers. The obvious fear is that the business will lose customers if the release isn't good enough.

Minimizing features in the [MRP] does not mean that one should release a system that will be useless for internal users or customers. The features that are included in a release should also be of high quality. Pain is caused by the features that are missing, not by including poorly built features.

h3.Mitigating pain
There are many strategies that make it possible to release a very limited version:

* Use [Limited releases] so that only a few users/customers are affected
* [Pain relievers] can compensate users and customers for any inconvenience they experience
* [Differentiators] can give users and customers gains that outweigh the losses

The important thing is to make all stakeholders understand why the release must be limited and give them an idea of how long it will take to get a more complete version deployed. Once the release is in production it is much easier to prioritize functionality based on business value.

h3. Pain in [replacement project]s
Getting stakeholders to accept a painful release is particularly hard in a [replacement project]. The gut feeling in the business will be that you must wait until "the new system is as good as the old one". One of the core responsibilities of the product owner is to work with stake holders and make them understand that it is in their interest to have as short releases as possible.