Change for Free
... you have a Product Backlog ordered by High Value First under a fixed-cost, fixed-scope contract and want to support customers with freedom to change requirements after development has started. You are supporting a single customer or a customer base represented by a unified perspective.
✥ ✥ ✥
Some PBIs (Product Backlog Items) are context-free, and you want to respond to customer changes under High Value First that are driven by their desire to increase their profitability. You don't want to allow changes that lead to significant rework, as that can lower your ROI. On the other hand, it takes very little investment to put a PBI on the Product Backlog and it is very little work to remove it or move it around.
Each PBI has an associated cost estimate that has been (or can be) provided by the team. The Product Owner knows the ROI of each item, and the customer is responsible for knowing how much value the item provides to them.
You have fixed price and fixed scope, yet requirements may still emerge. It doesn't serve the interests either of the customer nor the vendor to stick to a fixed list of deliverables if there is something to gain, and nothing to lose, by renegotiating.
The bottom of the requirements list is rarely mission critical for customers. However, they can still benefit if they can receive those items within the originally negotiated budget.
Therefore: Fix the price and the scope, and make a contractual agreement to commit to the top 80% of the PBIs as ordered according to their value to the customer; the vendor might exceed that 80% if the work can be done within the contracted cost. Offer customers the option of exchanging an emergent requirement for any existing PBI of equal (or lower) value to them, as long as the development cost of the new item is no more than the cost of the original.
✥ ✥ ✥
The item's cost should be estimated by the team(s) before the Product Owner commits to positioning it in the Product Backlog. Of course, this pattern doesn't apply to PBIs that are currently being worked on in a sprint. Such patterns are usually beyond the reach of negotiation.
In general, the vendor and customer can work as a team to share these benefits instead of accounting them individually.
This can become difficult if you are supporting multiple customers, since one customer's request will effect everyone's schedule, and this approach to the Product Backlog sets an expectation that successive deliveries will follow each other closely in order of business value.
See also Money for Nothing.
Author: Jim Coplien based on input from Jeff Sutherland