Change for Free

Free tailoring with purchase.

...you have a Product Backlog ordered by High Value First under a fixed-cost, fixed-scope contract between a vendor and a client. You want to support the client with the freedom to change requirements after development has started. You are supporting a single client or a client base represented by a unified perspective. The Development Team’s velocity (see Notes on Velocity) has a low variance (on the order of 10 or 15 percent). Either the team has prior experience in this domain, or there is some other verifiable expectation of being able to create an initial set of Enabling Specifications for the product. The prospect for emergent requirements, and requirements changes, is small but non-negligible.

✥ ✥ ✥

Some PBIs (Product Backlog Items) are somewhat context-free and independently deliverable, and you want to respond to client changes driven by clients’ desire to increase their profitability. You don’t want to allow changes that lead to significant rework, as that can lower the vendor’s ROI or other measure of value (see Value and ROI). On the other hand, it may take only a little investment to put a PBI on the Product Backlog, and it is very little work to remove the PBI or move it around.

Each PBI has an associated cost estimate that has been (or can be) provided by the Development Team. The Product Owner knows the ROI of each item, and the client is responsible for knowing how much value the item provides to them.

Even though you have fixed price and fixed scope, new requirements may still emerge. It serves the interests neither of the client nor of the vendor to stick to a fixed list of deliverables if there is something to gain, and nothing to lose, by renegotiating.

Anticipating that any up-front agreement of work on a complex product will not cover what clients really need, some firms have a business model based in large part on cornering the client into paying change fees for work they request after the initial delivery (see “Change for Free and Money for Nothing” in [1], ff. 193). Such practices erode trust, which in turn can lead to a climate of adversarial checks and balances in the long term—and all the inefficiencies that go with them.

The bottom of the requirements list is rarely mission critical for clients. 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 percent of the PBIs, ordered according to their value to the client. The vendor might exceed that 80 percent target if it can complete the work within the contracted cost. Offer clients 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 team orders the Product Backlog to create Regular Product Increments that can accommodate client changes and increase overall value (at least to the client, but preferably to both vendor and client) without increasing cost. With the cost capped, the vendor can establish a fixed price that yields fair profit. The focus is on Greatest Value, both for the vendor and client, in the time frame that each expects.

This pattern works best for highly experienced Scrum Teams that are longstanding Stable Teams and that are highly experienced in building products in the client domain. The Development Team(s) should estimate each item’s cost before the Product Owner positions it in the Product Backlog. The success of this pattern depends on the team’s ability to estimate all PBIs accurately up front. This in turn suggests that most PBIs should have the stature of an Enabling Specification early on, so this pattern works best in low-risk domains or domains very familiar to the team. Of course, this pattern doesn’t apply to PBIs that the Development Team is working on in the current Sprint. Such PBIs are usually beyond the reach of negotiation.

In general, the vendor and client can work as a team to share these benefits instead of accounting them individually; see Development Partnership. Jeff Sutherland describes how it works in [1]:

That’s why I came up with the idea of ``Change for Free.'' In a standard fixed-price contract, just say changes are free. List all the functionality you expect; for example, if you’re building a tank, you want one that can go seventy-five miles per hour and shoot ten rounds a minute, has seating for four, has AC, etc.—everything you think you need for that tank. The builder looks at that description and says, ``Hmm, making that engine, I’ll call that 100 points, the loading mechanism, let’s call that 50, the seating, 5...'' on down the list. At the end there is a set number of points for each feature. Then every Sprint, the customer, who in this scenario is contractually obligated to work closely with the Product Owner, can change priorities completely. Any item or feature in the Backlog can be moved anywhere else. And new features? No problem: just drop equivalently sized features from the deliverables. ``Oh, you want a laser-guided system now? Well, that’s 50 points of work—to compensate for that addition, let’s drop 50 points of low-priority features from the bottom of the Backlog.''

This approach can become unwieldy if you are supporting multiple clients, since one client’s request will affect everyone’s schedule, and this approach to Product Backlog management sets an expectation that successive deliveries will follow each other closely in order of business value.