A scope of work is the difference between a 6-week sprint and a 16-week death march. We have signed 60 plus dev retainers at ScubaDev and one pattern holds: the engagements that stayed in scope had a scope of work with these seven sections filled in before kickoff.
The seven sections every software scope of work needs are objective, deliverables, acceptance criteria, timeline, change order process, exclusions, and payment terms. The most-missed section is exclusions. The second most-missed is change order process.
This guide walks through the seven sections, shows the one-page version we actually use, and links to the free downloadable scope of work template we keep in our template pack.
Below the surface
Every section below is one piece of the scope. Each section is what we ask for, what we put in our own contracts, and what we look for when a client hands us their paperwork. The infographic shows all seven sections in one map. Use it as the table of contents for the rest of the guide.
By the numbers
What the SOW has to protect
-
Signed retainers
60+
Dev retainers signed at ScubaDev. The pattern below holds across all of them.
-
Required sections
7
Every software scope of work needs all seven. Missing two or more produces scope creep.
-
Sprint scope
1page
The under-$20K sprint scope is one page. Same seven sections, just shorter.
-
Template version
v8+
Every scope document we run is at least version 8. We update after each surprise.
The failure modes
Why scope of work documents fail
Three failure patterns, observed across 60 plus software engagements. Each one alone produces scope creep. Two together produce a death march.
- 01
No acceptance criteria
A scope that says "build a customer dashboard" is not a scope, it is a wish. Acceptance criteria turn a wish into a bill of materials. "Customer dashboard with the following 7 widgets, each pulling from the following 3 data sources, rendered on mobile and desktop, tested in Chrome and Safari." That is a scope. The first version is a fight you are going to have eventually. Have it before kickoff.
- 02
No exclusions
Exclusions are the "this is not included" list. No exclusions means anything the client asks for is a fight to decline. Real exclusions list the obvious omissions (SEO, ongoing maintenance, hosting fees, third-party tool subscriptions) and the non-obvious ones (data migration from a previous system, user training, SOC 2 evidence collection).
- 03
No change order process
Scope creep is not the enemy. Unmanaged scope creep is. A 1-page change order form, a fixed rate for changes, and a written rule like "changes go in the backlog for next sprint" keeps the primary scope clean and the relationship honest.
04 / The template
The 7 sections every software scope of work needs
Below is the structure we use. This is the abbreviated public version. The fully annotated Word and PDF versions with lawyer-reviewed clauses live in the Template Pack.
-
01 / Objective
One sentence. The business outcome the project produces.
Not "build a CRM" but "cut lead-to-first-call time from 48 hours to under 15 minutes." The objective is the north star that settles every later scope dispute. If a feature request does not serve the objective, it is a change order.
-
02 / Deliverables
A numbered list of artifacts. Be literal.
For software this usually means: production code in a specified repo, deployed to a specified environment, with documentation at a specified URL, with handoff to a specified person. "Repo at github.com/client/project with main branch deployed to app.client.com, README at /README.md, handoff to CTO Jane Smith" is a real deliverable. "Working software" is not.
-
03 / Acceptance criteria
For each deliverable, a written definition of done.
For features, this is user stories plus test conditions. For artifacts, this is file locations and documentation standards. The acceptance criteria are what you sign off on at the end. If they are vague, the sign-off is a fight.
Field rule. Acceptance criteria should be testable in under 30 minutes per deliverable. If your acceptance test takes longer than that, the criteria are not written tightly enough.
-
04 / Timeline
Milestones with dates. Not week-counts.
Not "6 weeks from start" but "Milestone 1: architecture approved by Feb 15, Milestone 2: first feature shipped to staging by Mar 1, Milestone 3: full scope on production by Apr 15." Dates let both sides track drift. Week-counts let the timeline slide invisibly.
Include a contingency clause. Two weeks of slack for unknowns is standard. If the engagement is high-risk (data migration, third-party dependencies, unclear specs), 20 percent slack is appropriate. Dependencies the client owns (API access, content, legal sign-off) get called out here with the date they are due.
-
05 / Change order process
The most skipped section. Three pieces.
One. Who can request a change. Usually the client-side project lead, not any stakeholder. This prevents the pattern where a VP walks into a meeting and verbally reshapes a feature.
Two. How changes get priced. We use a fixed rate per change request tier: minor (under 4 hours of work) is included in the retainer up to a monthly cap, major (over 4 hours) is a written change order with its own price and timeline. The rate should be in the scope.
Three. How changes get approved. Written approval, usually by email reply, before work starts. No verbal change orders. The moment a change starts without paperwork is the moment the engagement goes sideways.
-
06 / Exclusions
A bullet list of what is specifically not included.
Our default exclusions for software engagements:
- Hosting and infrastructure costs
- Third-party subscription costs (Stripe, SendGrid, Auth0, and similar)
- Content creation (copy, imagery, video)
- SEO strategy or content marketing
- Ongoing maintenance after handoff
- User training and documentation beyond the technical README
- Data migration from existing systems
- Compliance evidence (SOC 2, HIPAA, PCI) unless specifically scoped
- Design work beyond what is included in the deliverables
Exclusions are not adversarial. They set the buyer's expectations. A scope without exclusions leaves the agency to tell the client "no" on every request, which is the fastest way to poison a relationship.
-
07 / Payment terms
Net 15 or net 30. First payment due at kickoff.
Late payment clauses. Milestone payments if the engagement is fixed-price. Retainer billing dates if it is a subscription. Include the right to pause work if payment is overdue past X days.
For retainer engagements, include the pause and cancellation policy. The subscription-dev category popularized "pause any time, cancel any time with notice." We use the same structure on most engagements because it keeps clients committed only when they have work to queue.
The sister document
What goes in the Master Services Agreement instead
A scope of work handles project-specific terms. A master services agreement handles the relationship-level terms.
- 01
Confidentiality and IP ownership
NDA terms, code ownership, reusable framework carve-outs. The MSA is where these get nailed down once. The SOW references them.
- 02
Liability caps and warranty
Mutual liability cap, typically 12 months of fees. Warranty period for shipped code, typically 30 to 90 days. Both belong in the MSA.
- 03
Indemnification and governing law
Reciprocal indemnification, jurisdiction, dispute resolution. Most firms sign one MSA at the start of the relationship and reference it in every subsequent scope of work. Faster than negotiating a new contract every time.
If you are signing your first dev engagement, you want both. The Template Pack includes the MSA, SOW, and retainer agreement as a set with cross-references.
The internal practice
How we use this at ScubaDev
Three specifics because a template guide that does not show its own work is not trustworthy.
- 01
No code without a signed SOW
We require a signed SOW before any code gets written. No exceptions. A "trial sprint" is not an exception because it is itself a scoped engagement with its own mini-SOW.
- 02
Right-sized to the engagement
We use a 1-page SOW template for sprints under $20K and the full 7-section template for everything larger. The 1-pager has the same 7 sections, just shorter. The full template has lawyer-reviewed boilerplate for liability and IP.
- 03
Exclusions reviewed last, every time
We review the exclusions list as the last step in every scope. Our rule is "if we cannot think of 5 things to exclude, we have not thought hard enough about what this engagement is not." This single discipline has prevented more scope creep than every other process we run.
The other side of the table
Red flags in a client's own paperwork
Not every engagement starts with your scope. Sometimes the client has their own. Four flags to look for before you sign.
- 01 / Indemnification
Indemnification clauses that are not reciprocal.
You indemnify them for your work, fair. They indemnify you for their content and data, also fair. One-way indemnification is a no.
- 02 / IP assignment
IP assignments that include your tools and frameworks.
The code you ship is theirs. The reusable patterns, templates, and internal tools you brought to the engagement are yours.
- 03 / Warranty
Warranties with no time or scope limit.
Standard software warranty is 30 to 90 days post-delivery for bugs in shipped code. Unlimited warranty is a liability tail you cannot price.
- 04 / Non-compete
Non-compete clauses that prevent you from working in their industry.
Reasonable non-solicit (of their employees and direct customers) is standard. Non-compete by industry is not.
FAQ
How long should a scope of work be?
A: 1 to 2 pages for engagements under $20K. 3 to 5 pages for larger. The full Template Pack version is 5 pages because it covers enterprise cases.
Do I need a lawyer to customize this template?
A: For a standard engagement, no. For regulated industries (healthcare, finance, government), yes. Our Template Pack includes the notes on what needs legal review.
Can a scope of work be a Google Doc?
A: Yes, if both parties sign. We use PDFs with digital signatures for the audit trail. Google Docs work for drafts.
What goes in a scope of work vs a statement of work?
A: Functionally identical terms. "Scope of Work" is slightly more common in software. "Statement of Work" is slightly more common in enterprise consulting.
How often should I update the template?
A: Annually at minimum. When any engagement goes sideways in a way the template could have prevented, update the template. Every scope document we run at ScubaDev is at least version 8.
Which section is the most often skipped?
A: Exclusions. Second most-skipped is the change order process. Both produce scope creep. Both are 30 minutes of work to fill in. Both are in the template.
Is one signed SOW enough for a long retainer?
A: For a true retainer, yes. The retainer agreement defines the engagement, monthly cap, pause and cancellation policy, and rate card. Specific projects inside the retainer can be scoped with a 1-page SOW or a written sprint brief, all referencing the parent retainer.