14
Agile Contracts
The agile contract is different from traditional contracts in that scope, costs, and the amount of value to be delivered are somewhat tricky to calculate up front. It is highly probable that a detailed description is not present in the agile contract because of frequent changes on these types of projects. We need to address the agile value, “Customer collaboration over contract negotiation,” in order to truly understand the intent of agile contracting.
The main idea is to build the contract around the end product rather than adding in a placeholder for unknown changes. Readers are reminded that agile methods are conducive to a great deal of flexibility which allows for the accommodation of changing requirements and priority levels. As a result, creating acceptance criteria on agile contracts can be a cause of concern on the vendor side. We need to understand that agile projects support static costs and time; however, product scope is always going to be very dynamic. Why? The project must deliver high-priority, top-quality product features first under resource and time restrictions. This all boils down to the fact that the customer could possibly have (bad idea on the agile project) fixed prices and scope, but the estimates will be padded with an uncertainty buffer included in the price. From the customer perspective, the downside to this contracting rationale is they may end up paying for non-valued-added activities after the project is completed.
There also needs to be a certain amount of trust between the parties involved in the contract, otherwise it will be difficult for some vendors to accept. Creating a trusting relationship on agile projects requires vendors to be on-site, hands-on, and involved. If there is trust, then the expectation is that the end client will gain a competitive edge as a result of high value added at reasonable (preferably low) costs. The vendor, however, expects high profits and low risks which would mean that both parties have to meet at a middle ground. Agile contracting is not a sound idea for the client–vendor relationship where there are no face-to-face interactions or trust. We will now discuss several contract types that are designed just for agile projects.
STORY POINT BILLING MODEL*
A story point is a comparative measure of project work. For example, an agile team may decide that it takes one story point to complete a task. The team has previously agreed that one story point equates to one hour of work. From that basis, two story points equate to two hours of work. Readers need to understand that the agile team decides the value of a story point. Another example would be that the agile team agrees that one story point is equal to one day of work. The value of a story point is decided and agreed upon by the agile team, but the developers have the most input into what a story point actually amounts to because they are the ones building the product. A story point could equate to a day, a week, or even a month based on what the team decides to use as the basis.
The story point billing model was designed as a win–win contracting solution for both the vendor and the customer. This model is based on using story points as the basis for calculating costs on the agile projects. The customer is charged only for the actual number of story points that are delivered as “done” within iterations. To clarify how story points can be used to bill the customer, let’s say, for example, that a story point represents one hour of work. One hour of work costs $50.00. If the team has developed 100 story points at $50.00 and the customer agrees on the price, then the customer is billed for (100 times $50.00) which equals to $5,000.00. Let us begin by explaining how this model is calculated. There are three steps involved:
Formulate the triangulation wall used for estimation. There are three sides to the triangulation wall. Triangulation is used to estimate a user story based on a story’s relationship to other stories. Triangulate means “to divide into triangles.” Because triangles are three sided, we use three areas against which to form our estimates:
With traditional project management model the three sides are:
Scope (fixed)
Time (varied)
Costs (varied)
With the agile model, the three sides are:
Costs (fixed)
Time (fixed)
Scope (varied)
A wall is considered to be a set of standard tasks for a story within a particular type of technology and purview. For example, we are building a product web application that receives data from two distinct sources. A story in this example would have requirements to import data from the two sources and then create a report. The resultant user story might be worth two story points (because of two data sources) for an example. This is how the user story could be mapped to the triangulation wall item(s) in regard to how many resources, how much time, and what functionality.
Calculate story point and dollar conversions. Once the triangulation wall is established, the cost of developing a story point must be calculated. This would be a time-boxed phase based on agreement by all parties. The actual costs of developing a story point can be calculated based on the number of stories accepted and the amount of money expended during iterations. The billing model is at this point a story point model.
Define the scope of the iteration(s). The scope determines how much revenue the vendor can generate based on the story points. The vendor may only bill the customer based on the number of accepted story points per iteration. This provides for a consistent generation of income for the vendor. The scope determines the number of story points within the iteration. Let’s say, for example, that the scope of a single iteration is 55 story points. The vendor and customer agree that a single story point costs $100 to develop. The scope calculated in dollars for this particular iteration would be $5,500.
The story point billing model is indeed a win–win situation for both the customer and vendor. The customer is satisfied with high value being delivered quickly and frequently, and the vendor generates revenue each time value is delivered under a unique billing model with relatively low risks. Readers are cautioned that this billing model may not be suited to all agile projects. The triangulation wall can be intimidating and complicated for some projects because of the requirements to convert story points into dollar equivalency. This model is recommended for the following types of agile projects:
• A project where the requirements are constantly changing
• A new product is being developed
• Spanking brand new agile vendor–customer relationship
MONEY FOR NOTHING AND CHANGE FOR FREE
According to Jeff Sutherland (2013) the “money for nothing and change for free” strategy has been widely adopted as the foundation for many agile contracts.* This contracting strategy is best for cases where a customer asks for an up-front estimate on an entire contract. Basically, this type of contract provides for early termination under certain conditions and is flexible when changes are needed on the project. Sounds good so far, right? In addition, this contract begins as a fixed price and it includes time and materials for any add-on work. A “change for free” option is included and this is where the contract terms get interesting. This “change for free” clause can only be implemented by the customer in the case where the work is continued with the same team in place for all iterations and the customer is fully engaged. In the event this clause is voided, then the contract goes back to time and materials billing. If the customer stays with the same team and if the Product Owner wants to make changes at the end of an iteration (i.e., re-prioritize the product backlog), then these changes are free if and only if the total contract work has not changed (i.e., the scope has not changed). This results in additional items being added at zero costs.† In regards to the “money for nothing” clause, a customer has the right to terminate the contract at the end of any iteration. In the event that the customer feels that there is very little value in continuing the project, he or she has the right to terminate the contract and pay the vendor 20% of the remaining contract as the penalty for ending the project. This is considered to be “money for nothing” because the vendor is getting paid and the work will have ended. Readers must understand that at this point, the customer would have already used up 80% of the project budget. At any time when the customer fails to fully participate in the iterations and/or the parties are unable to agree on costing, the contract rates return to time and material billing. Let’s elaborate a little more for a detailed understanding of what this agile contract type entails.
The “change for free” clause in the contract can only be executed if the customer continues to work with the “same” team on every iteration for the project. This in essence means that the customer is doing what he or she should be doing as per this type of contract. In the case where the team changes, this contract clause is completely voided and the contract is now considered to have a time and material basis. On the other hand, if the customer continues to be engaged as required, the Product Owner can begin to reprioritize the backlog at the end of an iteration. The “change for free” clause is executed if the customer continues to participate in all of the iterations for the entire project. This affords the customer the right to make changes to the project’s scope without any additional costs if and only if the total scope of work has not changed. New features can be legally added for free if items with equal scope are eliminated from the contract. The customer “has” to be engaged and has the right to cancel the project early in the case where it is believed that there is inadequate return on investment (ROI) in the product backlog for additional iterations. The vendor can decide to agree to the contract termination during any period of time for 20% of the outstanding contract value.
This 20% is the “money for nothing” feature of the contract and it is designed to mitigate the risk of dealing with an idle agile team. The customer gets 80% of high value, the project is completed earlier than planned, the vendor gets 20% of the remaining contract value as a bonus (including the 80%) for the completed work, and everyone is happy! The money for nothing contract clause gives the customer an opportunity to cancel the project early if it is believed that there is insufficient ROI in the backlog. This would mean that no additional iterations will take place. If needed at a later time, additional releases can be added through time and materials billing. This contract type allows for a great deal of flexibility in making changes on the agile project. It begins with a fixed price contract, includes a time and material clause for additional work, and it includes the “change for free” and “money for nothing” contract clauses.
FIXED PRICE CONTRACTS
There are other types of fixed price contracts that are used on agile projects such as:
• Graduated Fixed Price Contract: The hourly rate is based on finishing early (highest rate), finishing on time (second highest rate), or finishing late (lowest rate). For example, the rates are graduated as $150/hour, $130/hour, and $120/hour.
• If the work is completed early, then the customer is happy because the overall price is lower as a result of fewer hours used.
• However, if the project is late, then the vendor gets paid more overall, because of a higher number of hours used at a lower bill rate. Both parties are sharing the risks and the rewards based on the delivery schedule.
• If the vendor delivers early, then the customer is satisfied because of fewer overall costs. The vendor in this case is happy as well because of a higher profit margin.
• When the vendor delivers late, their bill rate is the lowest and they might possibly be displeased. The vendor will get paid more in overall costs because of having to use more hours, but with a lower profit margin. The customer in this case has to pay more in overall costs and may also be displeased.
• Fixed Price Work Packages Contract: This is a contract where the work is broken down into fixed price work packages. The first question would be, “Why do we need this?” This type of contract mitigates risks associated with under-or overestimating a piece of work by decreasing both scope and costs for the work that is being estimated. For example, a company can break down their statements of work (SOW) into distinct work packages where each has a fixed price. During the course of work, the vendor has the opportunity to estimate the work packages again as a result of the identification of new information and risks. The customer has the chance to revisit the prioritization of the work that is left based on developing costs. The vendor has the chance to update costs when new details present themselves and the need to add contingency costs is no longer relevant. Any additional changes that are pertinent can then be added into the work packages. In the case where extra funds are actually needed, it won’t be difficult or questionable to do so at any particular point of time going forward.
CHAPTER SUMMARY
It is not uncommon in the agile world for customers and vendors to create custom-built contracts that support a project’s specific needs. In these cases, the customer retains the right to reprioritize the product backlog and eliminate the need for vendors to add contingency costs to the total contract price. Both the customer and the vendor are protected when using customized agile contract types.