Unfortunately, there are no established practices for the Scrum pattern "Change for Free" so far. For this reason, we subsumed our own Lessons Learned in the form of four Best Practices and four Bad Practices, which we want to present in this "cheatsheet". Also available in German: http://www.slideshare.net/headrevision/change-for-free-cheatsheet

1. BACKGROUND
INTENT
PROBLEM
SOLUTION
CHANGE FOR FREE
A supplier implements a customer project with an (initially) fixed scope for a fixed price. The
customer is interested in an agile approach - particularly in the option to change or detail
requirements during the implementation.
The customer cannot or does not want to follow an agile methodology and actively take a role in
an agile process (eg. Product Owner in Scrum).
The supplier offers the customer a “Change for Free” option.
During the implementation of the project, requirements can be exchanged with initially unagreed requirements
without additional costs if following conditions are met:
1 ) The implementation of the requirements to remove has not started.
2 ) The implementation effort of the requirements to remove is identical to that of the requirements to add.
Concept of “Change for Free” taken from Jeff Sutherland, Money For Nothing and Your Change For Free: Agile Contracts, 2008, Scrum Inc.
User Stories examples inspired by Mike Cohn, User Stories Applied: For Agile Software Development, 2004, Addison-Wesley
REFERENCES
CHANGE FOR FREE Best Practices and Bad Practices for Agile Fixed-Price Projects
© 2015 YMC AG www.ymc.ch

2. S
C
Requirements whose implementation is in progress
Not necessarily with the use of iterations (Sprints in Scrum)
IMPLEMENTATION
Effort for the implementation of a particular (coarse-grained or fine-grained) requirement
Either estimated relatively to each other in an arbitrary measurement unit (generally Storypoints) or absolutely in a unit of time (eg. man-days)
The effort of a coarse-grained requirement should equal the sum of the efforts of all the fine-grained requirements contained in it
EFFORT
CUSTOMER
SUPPLIER
Defined by coarse-grained requirements and possibly further contractual agreements
SCOPE
Not (yet) detailed enough for an immediate implementation
Often in the form of a broad User Story (also called Epic)
Example: “As a registered user, I want to edit my account information.”
Is detailed (in the course of the project) by decomposition into several fine-grained requirements















COARSE-GRAINED REQUIREMENTS
Describes a self-contained functional part of a coarse-grained requirement
Often in the form a detailed User Story
Example 1: “As a registered user, I want to edit the shipping and billing addresses stored in my account.”
Example 2: “As a registered user, I want to edit the credit card information stored in my account.”
Often specified by using acceptance criteria
Example: The user is warned if the credit card number is changed to an invalid one.
FINE-GRAINED REQUIREMENT
LEGEND
A
CHANGE FOR FREE Best Practices and Bad Practices for Agile Fixed-Price Projects
© 2015 YMC AG www.ymc.ch

3. C
The simplest case of Change For Free: The customer wants to add a new
(coarse-grained) requirement to the scope. Together with the supplier she decides which
existing requirement is removed from the scope in exchange.
#1Practice
EFFORT
C+S
++
+
-
--
Best Practice
Bad Practice
Bad Practice
Best Practice
CHANGE FOR FREE Best Practices and Bad Practices for Agile Fixed-Price Projects
© 2015 YMC AG www.ymc.ch

4. #2Practice
C
C
C+S
EFFORT
++
+
-
--
Best Practice
Bad Practice
Bad Practice
Best Practice
A single requirement can also be exchanged with multiple requirements - as long as
the (summed) effort matches.
CHANGE FOR FREE Best Practices and Bad Practices for Agile Fixed-Price Projects
© 2015 YMC AG www.ymc.ch

5. Furthermore, a sole coarse-grained requirement makes
the exchange easier, because you have to adapt only
one effort estimation.
#3Practice
A
B
C
D
A
BC
C+S
C
A
D
As in practice #2, but the requirements exchanged with each other are fine-grained
requirements with a shared coarse-grained requirement.
This practice is particularly recommended because the effort of fine-grained requirements is
estimatable with less uncertainty than the effort of coarse-grained requirements, and also for this
reason, the exchange involves reduced risk.
C
EFFORT
++
+
-
--
Best Practice
Bad Practice
Bad Practice
Best Practice
CHANGE FOR FREE Best Practices and Bad Practices for Agile Fixed-Price Projects
© 2015 YMC AG www.ymc.ch

6. ++
+
-
--
Best Practice
Best Practice
Bad Practice
Bad Practice
#4Practice
A
B
C
D
A
BC C
C
A
D
C
? S
EFFORT
There could be a technical dependency from the
removed requirement to another requirement which
only the supplier can identify. And by taking a fixed
value for the effort, you should modify the require-
ment (eg. by simplifying it) if necessary, which in turn
only the customer is eligible to do.
In principle, the customer should have the freedom to also add an unestimated
requirement to the scope, which is estimated in the course of the exchange.
In doing so, you should avoid that the requirement to remove is determined solely by the
customer and/or that the added requirement is “estimated” solely by the supplier by
just taking the unmodified effort estimation of the removed requirement.
CHANGE FOR FREE Best Practices and Bad Practices for Agile Fixed-Price Projects
© 2015 YMC AG www.ymc.ch

7. #5Practice
A
B
C
D AC
C+SB
C
++
+
-
--
Best Practice
Best Practice
Bad Practice
Bad Practice
EFFORT
A requirement that is being implemented should never be exchanged - regardless how
much progress has been done.
As noticeable in all practices from practice #3 onward, the fine-grained requirements of a
coarse-grained requirement that is being implemented can potentially still be exchanged because
they are self-contained.
CHANGE FOR FREE Best Practices and Bad Practices for Agile Fixed-Price Projects
© 2015 YMC AG www.ymc.ch

8. #6Practice
A
B
C
D
A
BC
C+S
C
EFFORT
++
+
-
--
Best Practice
Best Practice
Bad Practice
Bad Practice
Also, the case the other way around is problematic: If
the effort of the requirement to add is lower than the
effort of the requirement to remove, the customer
should get a discount, which is generally not provided
in fixed-price projects though.
Requirements with different effort each should never be exchanged with each other.
If the effort of the requirement to add is higher than the effort of the requirement being
removed, you cannot ensure without further actions anymore that the project can be
implemented in due time. In addition, a cost overrun (at the expense of the supplier)
would certainly be inevitable.
CHANGE FOR FREE Best Practices and Bad Practices for Agile Fixed-Price Projects
© 2015 YMC AG www.ymc.ch

9. A
B
C
D D
A
B
A
C
C
C+S
C C+S
#7Practice
EFFORT
++
+
-
--
Best Practice
Bad Practice
Bad Practice
Best Practice
Practice #6 can be corrected with this modification: Additionally to the exchange,
customer and supplier together (see practice #4) modify another requirement, such that
the summed efforts effectively stay the same.
CHANGE FOR FREE Best Practices and Bad Practices for Agile Fixed-Price Projects
© 2015 YMC AG www.ymc.ch

10. A
B
C
D D
A
B
A
C
C+S
C
#8Practice
C
C+S
EFFORT
++
+
-
--
Best Practice
Best Practice
Bad Practice
Bad Practice
Practice #7 should be avoided if the modified requirement and requirements exchanged
with each other have no relation with regard to content, because the procedure of the
exchange combined with the modification of another requirement comes with a higher
complexity and, therefore, a higher risk. (see also practice #3).
CHANGE FOR FREE Best Practices and Bad Practices for Agile Fixed-Price Projects
© 2015 YMC AG www.ymc.ch