This document is a guide to writing agile contracts. Unlike traditional contracts, an agile contract does not specify individual tasks to be completed by the Contractor. Rather, an agile contract specifies how the Client and Contractor interact, and how the Contractor is paid. The Deliverable Work performed for the contract is determined through an ongoing collaboration between the Client and the Contractor.
Agile contracts require a great deal of trust from both the Client and the Contractor. This trust is fostered through tight feedback cycles and well-defined responsibilities that both parties can expect from each other. More so than traditional contracts, an agile contract requires active participation from the Client.
This guide is designed such that Contractors can integrate their work and schedules into the Client’s existing Scrum process.
Note: this guide does not prescribe any specific tools or methods for following the process. Your organization might use Jira, or Trello, or Post-It notes to organize your Sprints. If you expect the Team to use any specific tools, or adhere to any specific policies, they should be included in the final contract.
This guide was derived from the following sources:
- The Agile Contracts Primer from http://www.agilecontracts.org
- The Scrum Primer from http://scrumprimer.org
- Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland
- {CLIENT_NAME} Contract Agreement
- Summary of Vision
- Expectations and Responsibilities
- Scrum Process
- Payment
- Termination
- Federal, State, and Local Payroll Taxes
- Notice to Independent Contractor About Its Tax Duties and Liabilities
- Responsibility for Workers' Compensation
- Independent Contractor Status
- Signatures
- Appendix A: Glossary
This agreement is made on {SIGNING_DATE}, by and between independent contractor {CONTRACTOR_NAME}, referred to as the Contractor, and {CLIENT_NAME}, referred to as the Client. The Contractor and the Client agree as follows:
The Summary of Vision clearly outlines the scope, vision, and business motivation of the contract. It should be written in plain language, and follow a Geoffrey Moore style vision statement:
For (target customer)
Who (statement of the need or opportunity)
The (product name) is a (product category)
That (key benefit, compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)
The Summary of Vision should also include a synopsis of the general contract, price, and payment model. Mention should be made that the contract is based on the Scrum methodology.
This contract will begin on {START_DATE} and will continue until the work outlined by this Summary of Vision is complete, or either party terminates the contract.
Everyone working on the contract—including both the Client and the Contractor—known collectively as the Team, must participate in the Scrum process. Both the Client and the Contractor have well-defined roles and responsibilities in the Scrum process. In this way, the entire Team is responsible for the success of the contract.
Any additional responsibilities that may be expected from each role should also be listed in the final contract.
Responsible for providing the vision for what the contract is going to accomplish. Responsible for identifying and prioritizing product features. Responsible for deciding how much work the Client is willing to pay for during any given Sprint.
The Product Owner must attend the following meetings when possible:
- Initial Backlog Generation
- Backlog Grooming
- Sprint Review
The Product Owner may optionally attend the following meetings:
- Sprint Planning
- Standup
- Sprint Retrospective
Responsible for coaching the rest of the team through the Scrum process. Responsible for eliminating impediments and removing waste; does whatever is in their power to help the contract be successful.
Ideally the role of Scrum Master should be performed by someone other than the Product Owner. However, for smaller teams or smaller contracts, both roles may be performed by a single person.
The Scrum Master must attend the following meetings when possible:
- Initial Backlog Generation
- Backlog Grooming
- Sprint Planning
- Standup
- Sprint Review
- Sprint Retrospective
Responsible for completing the Deliverable Work for the contract. Takes the Product Owner's vision and makes it a reality. The Development Team is the sole role fulfilled by the Contractor, and may consist of one or more people.
Any ongoing work expected from the Contractor that does not fit the Scrum model – whether explicitly paid or not – should also be listed here.
The Development Team must attend the following meetings:
- Initial Backlog Generation
- Backlog Grooming
- Sprint Planning
- Standup
- Sprint Review
- Sprint Retrospective
Both the Client and the Contractor must participate in the Scrum process. Active participation from both parties forms the foundation of trust that makes the contract a success. Sprints
The contract as a whole is organized into 1-4 week blocks of time known individually as a Sprint. Sprints follow a predefined schedule of meetings and checkpoints. Each Sprint starts with two meetings: the Backlog Grooming meeting and the Sprint Planning meeting. There is a short Standup meeting each day of the Sprint. Each Sprint concludes with two meetings: the Sprint Review meeting and the Sprint Retrospective meeting.
The beginning of the contract starts with a special one-time meeting known as the Initial Backlog Generation meeting.
The Contractor will be paid at the end of each Sprint based on the payment structure detailed in the Payment section.
Summary: Generate an initial list of potential work for the contract.
Participants: The entire Team (Product Owner, Scrum Master, and Development Team).
Duration: Anywhere between 1-4 hours, but no longer.
The entire Team shall meet at the outset of the contract to generate an initial list of potential work for the contract. This list is known as the Backlog. Each item of work on the Backlog is known simply as an Item.
The purpose of the Initial Backlog Generation meeting is to get as many raw ideas down on paper as possible. The meeting is equal parts brain-storming and design. The Team should strive to make the initial Backlog as comprehensive as possible, but at no point should the Backlog be considered complete. The Backlog is a constantly evolving roadmap of work that may be completed on the contract.
It's possible there may already exist a list of potential work to be added to the contract. Each existing Item should be reviewed and discussed by the Team so everyone fully understands the work involved. Where possible break large Items into more well-defined smaller Items.
Summary: Review, estimate, and prioritize items on the Backlog.
Participants: The entire Team (Product Owner, Scrum Master, and Development Team).
Duration: Anywhere between 1-2 hours, but no longer.
The purpose of Backlog Grooming is to review, prioritize, and estimate Items on the Backlog before any planning is done at the outset of the Sprint.
The Backlog includes any work that may potentially be completed on the contract. The Backlog is a constantly evolving list. In addition to changing internal requirements, there may be external factors that drive new tasking and priorities. At any point throughout the contract, any member of the Team may add additional Items to the Backlog. The Product Owner may also spend time during a Sprint augmenting, prioritizing, and refining the Backlog.
As such, the Backlog will change from one Sprint to the next. Backlog Grooming is an opportunity to ensure that the Backlog is up-to-date, organized, and that everyone is synchronized regarding tasking and priorities. Where possible, large Items should be decomposed into smaller, more well-defined Items.
Each Item on the Backlog should have a clear Done Condition that everyone understands and agrees upon. The Done Condition should unambiguously define when an Item may be considered complete, including any acceptance checks required by the Product Owner. This is also a good opportunity for the team to discuss details or concerns regarding any given Item, or how it fits into the contract as a whole.
An Estimated Complexity should be assigned to each Item on the Backlog. Each member of the Team should have input on the Estimate. The Estimate for any given Item should be agreed upon unanimously by the Team. If the Team does not agree on an Estimate, it should be discussed until agreement is reached.
Accurate Estimated Complexity is critical to forecasting how much work the Development Team can accomplish in a given Sprint. Estimates will likely start out less accurate at the beginning of the contract, and gradually become more accurate throughout the life of the contract.
Note: it may be the case that the Client is incentivized to underestimate Items, and the Contractor is incentivized to overestimate Items. The success of the contract is dependent on each party's willingness to resist those urges.
Any new information or external factors should be taken into consideration to refine existing Items and Estimates. Higher priority Items should be moved to the top of the Backlog. Items should be ordered by the Product Owner based on a combination of priority and estimated complexity.
High priority Items near the top of the Backlog should be more granular and detailed. Low priority Items near the bottom of the Backlog may be larger in scope and more vague. During Sprint Planning, Items are taken from the top of the Backlog and moved to the upcoming Sprint. Ideally, those items will have more detailed descriptions, more detailed Done Conditions, and more accurate Estimates. The reason Items near the top of the Backlog should be more granular and detailed is to make Sprint Planning faster and more accurate.
Summary: The Development Team forecasts how much work they can achieve in the upcoming Sprint, and selects Items from the top of the Backlog for inclusion on the upcoming Sprint.
Participants: Scrum Master and Development Team are required. Product Owner may optionally attend, otherwise should be available for questions.
Duration: Anywhere between 1-2 hours. If Sprint Planning takes longer than 2 hours, it may indicate that more time should be spent in Backlog Grooming, or that the Product Owner should be more actively grooming the Backlog throughout Sprints.
The purpose of the Sprint Planning meeting is for the Development Team to forecast how much work they can achieve in the upcoming Sprint, and reconcile that with how much work the Client is willing to pay for in the upcoming Sprint. It's important to note that the Development Team decides how much work to take on in any given Sprint.
The maximum amount of work the Client is willing to pay for in a Sprint is detailed in the Payment section of the contract. For an Irregular Sprint, the Product Owner is responsible for determining the maximum amount of work the Client is willing to pay for in that Sprint. The Scrum Master is responsible for knowing and communicating that amount to the Development Team. The amount of work the Client is willing to pay for may be negotiable, in which case the Product Owner should be available for discussion.
Part of this dialog may include determining the duration of the Sprint. Sprints should be between 1-4 weeks, and usually maintain the same duration throughout the course of a contract. However, there are a variety of reasons to try different durations for Sprints. Expect some experimentation with Sprint duration early in the life of the contract. Depending on the Client, the Contractor, and the type of work involved, longer or shorter Sprints may be more appropriate for any given contract.
Before the Sprint Planning meeting commences, the Backlog should be fully estimated and prioritized. The more care given to grooming the Backlog, the easier the Sprint Planning meeting will be. Items should be moved from the top of the Backlog to the current Sprint, until enough Items have been included to fulfill the Development Team's forecast.
The Sprint begins at the conclusion of the Sprint Planning meeting. Outside of extraordinary circumstances, the scope of a Sprint should not be modified once it begins. Approval from both the Development Team and the Product Owner is required to modify the scope of a Sprint.
Summary: The Development Team announces what they've done since the last Standup, what their goals are for the next Standup, and what they're blocked by.
Participants: Scrum Master and Development Team.
Duration: No longer than 15 minutes.
The purpose of the daily Standup is to keep the Team synchronized and afford transparency into the Development Team's progress.
Each Business Day of a Sprint—except on Sprint Planning and Sprint Review days—each member of the Development Team announces what they've done since the last Standup, what their goals are for the next Standup, and what they're blocked by. The Scrum Master is responsible for removing impediments that are blocking the Development Team. This is often accomplished by communicating and coordinating with the Product Owner.
If there are any blockers, or any Items that require further discussion, those discussions should be tabled until after the Standup. The discussion can be picked up again immediately after the Standup, but it should not hold up the remainder of the meeting.
Depending on the needs of the contract, the daily Standup may optionally be entirely text-based. A Standup post may be made via email, Slack, or other chat application. Whatever form the Standup takes, the content should always contain the three main points:
- Done Since Last Standup
- Goals for Next Standup
- Blocked By
Summary: The Development Team presents the work they've completed over the course of the Sprint for inspection by the rest of the Team.
Participants: The entire Team (Product Owner, Scrum Master, and Development Team), plus any other stakeholders, and anyone else that is interested in joining.
Duration: About 1 hour for every week in the Sprint.
The purpose of the Sprint Review is for the Product Owner to learn what is going on with the product, and for the Team as a whole to better understand the needs of the Product Owner. The Sprint Review is not just a demo, it's a back and forth collaboration used to inform the direction of the contract.
The Sprint Review takes place at the end of each Sprint. The entire Team, any other stakeholders, and anyone else that's interested should attend the Sprint Review. All of the work completed over the course of the Sprint should be presented for inspection. Whenever possible, a hands-on demo should be made available for the Product Owner and anyone else. Anyone present is free to ask questions and give input.
The Sprint Review is the best opportunity to provide course corrections on the direction of the contract. It may be the case that the Development Team executed flawlessly on the Sprint—each Item was completed exactly as desired—yet the results are not at all what the Product Owner envisioned. This scenario is not a failure of the contract. Rather, this is exactly how the contract is designed to operate. By requiring completed Items to be inspected during Sprint Review, changes can be made to the Backlog as early as possible.
It's natural and expected for new requirements to arise during the course of a Sprint Review. Seeing a product come to life often spurs new ideas and inspires design discussion. New requirements should be added as Items on the Backlog as they arise. Existing Items should be updated as needed according to the Product Owner's changing requirements.
Summary: The Team discusses what went well and what went poorly during the Sprint.
Participants: Scrum Master and Development Team are required. Product Owner may optionally attend, otherwise should be available for questions.
Duration: About 30 minutes-1 hour, but no longer.
The purpose of the Sprint Retrospective is for the Team to refine and improve their own internal processes.
The Sprint Retrospective is the culmination of the feedback cycle. It's a meta-meeting. While the Sprint Review gathers feedback about the product, the Sprint Retrospective gathers feedback about the process itself.
The Items on the Sprint are reviewed by the Scrum Master, the Development Team, and optionally the Product Owner to determine which Items were completed, which are incomplete, and what follow-on work might be required. A final tally of completed Items is compiled for the purposes of payment. Both the Product Owner and the Development Team must agree and sign-off on the final tally.
The Sprint Retrospective is also a good opportunity for either the Client or the Contractor to discuss the health of the contract. If either party desires to terminate or renegotiate the contract before the next Sprint, this is the time to talk about it.
Payment will be made to the Contractor at the end of every Sprint. The amount of payment will be based on the work completed during the Sprint. There are a variety of payment structures that lend themselves to payment after each Sprint:
- Time and Materials
- Time and Materials With a Per Sprint Cap
- Fixed Price Per Sprint
- Fixed Price Per Estimated Complexity (Story Points)
There are a variety of other payment structures, but they mostly do not lend themselves to payment after each Sprint.
The Contractor shall track all time spent working on each Item. At the conclusion of each Sprint, the Contractor shall be paid ${HOURLY_RATE} per hour for each hour worked on all completed Items during the Sprint.
Hours worked on incomplete Items will be pushed to the next Sprint, and paid at the end of the Sprint in which the Item is completed.
If at the end of a Sprint, a partially complete Item can clearly be broken down into two smaller Items, where one of those items may be considered complete, then—at the discretion of the Product Owner and Development Team—the Item may be split with the unfinished work moved to the Backlog in a new Item. If such a split is made, the Contractor may be paid for the hours worked on the completed Item.
This payment structure is highly flexible, but requires a great amount of trust in the Contractor. It runs the risk of burning through the Client's budget too quickly.
The Contractor shall track all time spent working on each Item. At the conclusion of each Sprint, the Contractor shall be paid ${HOURLY_RATE} per hour for each hour worked on all completed Items during the Sprint, not to exceed the number of Contract Hours in the Sprint. There are {CONTRACT_HOURS} Contract Hours for each Business Day in the Sprint. A Business Day is considered any day Monday-Friday that is not a Federal holiday in the US.
If the Development Team completes all the Items on a Sprint in fewer hours than the number of Contract Hours for that Sprint, then the Development Team may add additional Backlog Items to the Sprint with written approval from the Product Owner.
If the Contractor works more hours than the number of Contract Hours in the Sprint, the excess worked time will remain unpaid without written approval from the Product Owner. If the Contractor foresees that they will run over the number of Contract Hours for a given Sprint, they may request additional Contract Hours from the Product Owner for that specific Sprint. Overages are an indication that the Development Team should adjust the forecasted amount of work they can handle for future Sprints.
Hours worked on incomplete Items will be pushed to the next Sprint, and paid at the end of the Sprint in which the Item is completed.
If at the end of a Sprint, a partially complete Item can clearly be broken down into two smaller Items, where one of those items may be considered complete, then—at the discretion of the Product Owner and Development Team—the Item may be split with the unfinished work moved to the Backlog in a new Item. If such a split is made, the Contractor may be paid for the hours worked on the completed Item.
This payment structure allows for maximum contract flexibility while preventing the Contractor from prematurely burning through the Client's budget.
The Contractor shall be paid ${DAILY_RATE} per Business Day in the Sprint. A Business Day is considered any day Monday-Friday that is not a Federal holiday in the US.
This payment structure works well when the Contractor is expected to work on the contract full time.
The Contractor shall be paid ${STORY_POINT_RATE} per unit of Estimated Complexity for each completed Item on the Sprint. Incomplete Items will be pushed to the next Sprint, and paid at the end of the Sprint in which the Item is completed.
This payment structure may result in contract dysfunction, as it incentivizes the Client to underestimate complexity and the Contractor to overestimate complexity.
From time to time, there may be Sprints that require a different payment structure. For example, there may be an event that requires the Contractor to be “on-call” for the duration of the Sprint. For any Sprint that requires a different payment structure, an addendum can be made to the contract that specifies any changes for that specific Sprint. Unless otherwise specified, the normal Sprint and payment schedule will resume after the Irregular Sprint.
Generally, performance bonuses and penalties should be avoided. Both incentives and penalties foster a competitive us-vs-them relationship between the Client and Contractor, rather than cooperation. There is ample evidence incentives lead to increased gaming, a reduction in transparency and quality, and other dysfunctions.
However, there may be contract work that does not fit the Scrum-based Sprint model. For example, any kind of daily or ongoing maintenance expected to be performed throughout the life of the contract. For this kind of work, a short clause can be added to the Payment section outlining the work and the payment that can be expected. The work should also be noted under the Development Team's responsibilities.
Other forms of payment may also be added in additional clauses under the Payment section. For example, a signing bonus to be paid upon the agreement and signing of the contract.
Either party may terminate the contract at any time. If the contract is terminated during the course of a Sprint, then the Sprint is shortened and considered to be concluded at the time of termination. If the contract is terminated at the natural end of a Sprint, then the Sprint is concluded as normal. In either case, the agreed-upon terms and payments will be honored for the concluded Sprint.
The Client shall not withhold or pay federal, state, or local income taxes or payroll taxes of any kind on behalf of the Contractor or the employees of the Independent Contractor. The Client shall not treat the Contractor as an employee with respect to the services performed hereunder for federal, state, or local tax purposes.
The Contractor understands that he or she is responsible to pay, according to law, the Contractor's federal and state income taxes, and that Client is not withholding or paying any portion of Contractor's taxes. If the Contractor is not a corporation, the Contractor further understands that the Contractor may be liable for self-employment (Social Security) tax, to be paid by the Contractor according to law.
No workers' compensation insurance shall be obtained by the Client covering the Contractor or employees of the Contractor. The Contractor shall comply with the workers' compensation law concerning the Contractor and the employees of the Contractor.
The Contractor expressly represents and warrants to the Client that (1) he or she is not and shall not be construed to be an employee of the company and that his or her status shall be that of an independent contractor solely responsible for his or her actions and inactions; (2) the Contractor shall act solely as an Independent Contractor, not as an employee or agent of the Client.
Client
______________________________________________________________
{CLIENT_SIGNATORY} Date
Contractor
______________________________________________________________
{CONTRACTOR_SIGNATORY} Date
Agile Contract: A contract that specifies how the Client and Contractor interact, rather than specifying the actual work to be completed on the contract.
Backlog: An evolving list of prioritized Items to be completed on the contract.
Backlog Grooming: A meeting to review, prioritize, and estimate the Items on the Backlog.
Business Day: Any day Monday-Friday that is not a Federal holiday in the US.
Client: The person, company, or organization paying for the work done on the contract; the customer.
Contract Hours: The maximum number of hours per Sprint the Client is willing to pay for in a Time and Materials based payment structure.
Contractor: The person, company, or organization that is paid to complete the work done on the contract.
Deliverable Work: Any completed work that is done on the contract.
Development Team: The sole role fulfilled by the Contractor in the Scrum Process; the team of people responsible for completing any Deliverable Work.
Done Condition: A clear set of conditions, including any acceptance checks required by the Product Owner, that unambiguously define when an Item may be considered complete.
Estimated Complexity: An estimate of the relative complexity of a Backlog Item.
Estimate: See Estimated Complexity
Forecast: The amount of work that the Development Team feels they can complete in a Sprint.
Initial Backlog Generation: A meeting to generate an initial list of work to be completed on the contract.
Irregular Sprint: Any Sprint which, for whatever reason, requires an alternate payment structure.
Item: A single, self-contained item of work with a clear Done Condition. Exists on the Backlog until moved to a Sprint during Sprint Planning.
Product Owner: A role fulfilled by the Client that is responsible for identifying and prioritizing work to be completed on the contract, and determining how much work the Client is willing to pay for.
Scrum: An iterative and incremental framework for managing product development.
Scrum Master: A role fulfilled by the Client that is responsible for coaching the rest of the team through the Scrum process, and removing any impediments. The Scrum Master is above all else, a facilitator.
Sprint: A repeated block of time between 1-4 weeks which delineates the Scrum process. The Sprint is the core iterative process in which work is planned, completed, inspected, and reviewed.
Sprint Planning: A meeting at the beginning of a Sprint to forecast the work that will be completed by the Development Team on the upcoming Sprint.
Sprint Retrospective: A meeting at the end of a Sprint to review how the Team and the Scrum process are functioning, and to determine what is working and what isn’t.
Sprint Review: A meeting at the end of a Sprint to review the work completed during the Sprint, and integrate feedback from all stakeholders.
Standup: A daily meeting to synchronize the Team; the Development Team announces three thing: what they’ve done since the last Standup, what they plan on doing by the next Standup, and what they’re blocked by.
Summary of Vision: Describes the purpose of the contract, and summarizes the scope of work and payment structure.
Team: The entire team of people who are working on the contract, including roles fulfilled by both the Client and Contractor (Product Owner, Scrum Master, and Development Team).
Thanks for sharing this comprehensive guide on time and materials contracts in outsourcing. It provides valuable insights into the benefits, risks, and key considerations of using this type of contract. I found another helpful article on time and materials contracts by Cleveroad (https://www.cleveroad.com/blog/time-and-materials-contract-in-outsourcing-all-you-need-to-know/) which further expands on the topic and offers practical tips for successful outsourcing engagements.