compared with
Current by Niklas Bjørnerstedt
on Oct 21, 2009 15:37.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (1)

View Page History
{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.