The preceding discussion might give you the idea that Staged Delivery works almost every time, but keep this limitation in mind.

Feature creep. The main risk associated with Staged Delivery is the risk of feature creep. When customers begin to use the first release of your product, they are likely to want to change what has been planned for the other releases.

The best way to manage this risk is not to use Staged Delivery if you're uncertain what features need to be developed. Pure Staged Delivery does not provide much flexibility to respond to customer requests. Staged Delivery works best when you have a broad and deep consensus about what should be in the product.

If you decide to use Staged Delivery, you can still build time into your schedule to accommodate unknown features. You might define the last stage as the stage for making late-breaking changes. By allocating that time, you make it clear to your customers that you intend to be flexible, but you also make it clear that you expect to limit the number of unknown features that you implement. Of course, when you get to the last stage you can renegotiate the schedule if your customers want more features than you have time for. By then your customers will have working software in their hands, and they might well find that their initial schedule goal is no longer as important as it once seemed.

In addition to these practices specific to Staged Delivery, you can use any of the general means of managing feature creep. Those are described in Chapter 14, Chapter 14.