SOFTWARE DEVELOPMENT STATEMENT OF WORK ====================================== Disclaimer — not legal advice. This template is provided free of charge, as is and with no warranty of any kind, and using it creates no attorney-client relationship. It is jurisdiction-neutral: you are responsible for adapting it, for your own legal and tax compliance, and for having a qualified professional in your jurisdiction review it before you rely on it. Full terms: https://trycolo.co/terms-of-use SOW reference: [SOW-NUMBER] | Version: [v1] | Date: [DATE] Developer: [YOUR BUSINESS NAME] ("Developer") | Client: [CLIENT LEGAL NAME] ("Client") Governing agreement: [SOFTWARE DEVELOPMENT AGREEMENT / MSA AND DATE] Product owner (Client): [NAME], [EMAIL] — prioritizes the backlog and accepts sprints. Technical lead (Developer): [NAME], [EMAIL] 1. Product overview ------------------- Problem: [WHAT IS BROKEN OR MISSING TODAY FOR WHOM] Users: [USER TYPE 1 — e.g. customers placing repeat orders]; [USER TYPE 2 — e.g. warehouse staff] Release 1 goal: [WHAT MUST BE TRUE WHEN RELEASE 1 SHIPS — e.g. customers can reorder from history and staff can see orders in one queue] Platforms: [ ] Web app [ ] iOS [ ] Android [ ] API only [ ] Admin panel Out of scope for this SOW: [e.g. native mobile apps, data migration from legacy system, payments, reporting dashboard] 2. Backlog and acceptance criteria ---------------------------------- ID | User story | Priority | Estimate | Acceptance criteria ----- | ------------------------------------------------- | -------- | ----------------- | ----------------------------------------------------------------------------------- US-01 | As a [USER], I want to [ACTION] so that [OUTCOME] | Must | [N] pts / [N] hrs | Given [CONTEXT], when [ACTION], then [RESULT]. Given [...], when [...], then [...]. US-02 | As a [USER], I want to [ACTION] so that [OUTCOME] | Must | [ESTIMATE] | [CRITERIA] US-03 | As a [USER], I want to [ACTION] so that [OUTCOME] | Should | [ESTIMATE] | [CRITERIA] US-04 | As a [USER], I want to [ACTION] so that [OUTCOME] | Could | [ESTIMATE] | [CRITERIA] Non-functional requirements: Area | Requirement ------------------------ | ----------------------------------------------------------------------------------- Performance | [e.g. p95 API response under [N] ms at [N] concurrent users] Security | [e.g. authentication via [METHOD], passwords hashed, role-based access for [ROLES]] Accessibility | [e.g. WCAG 2.2 AA for customer-facing screens] Browser / device support | [LIST] Data retention | [RULE] 3. Definition of done --------------------- A story is done when all of the following are true: 1. Code is in the shared repository on the main branch via a reviewed pull request. 2. Automated tests for the story pass; overall test suite passes. 3. The story is deployed to staging. 4. Every acceptance criterion has been checked on staging by the Developer. 5. No open critical or high severity bugs against the story. 6. User-facing or API changes are documented in [README / API DOCS / CHANGELOG]. 4. Environments --------------- Environment | Purpose | Hosted in | Paid by | Who can deploy ----------- | ------------------------------- | -------------------------------- | --------- | -------------------------------------------- Development | Day-to-day building | Developer machines / [SERVICE] | Developer | Developer Staging | Sprint demos and Client testing | [CLOUD PROVIDER], Client account | Client | Developer Production | Live users | [CLOUD PROVIDER], Client account | Client | Developer, only with written Client approval Test data: staging uses [ ] synthetic test data [ ] anonymized copy of production. Real personal data is not used outside production. 5. Sprints and milestones ------------------------- Sprint length: [2] weeks. Planned sprints: [N]. Sprint demo: [DAY], [TIME] [TIMEZONE]. Sprint | Dates | Planned stories | Milestone payment ------------- | ------- | ---------------------------------------------- | ------------------- 0 — Setup | [DATES] | Repo, environments, CI pipeline, auth skeleton | [CURRENCY] [AMOUNT] 1 | [DATES] | [US-01, US-02] | [CURRENCY] [AMOUNT] 2 | [DATES] | [US-03, US-04] | [CURRENCY] [AMOUNT] [N] — Release | [DATES] | Hardening, release to production | [CURRENCY] [AMOUNT] | | Total | [CURRENCY] [TOTAL] Fee basis: [ ] Fixed per sprint as above [ ] Time and materials at [CURRENCY] [RATE] per hour, capped at [N] hours per sprint without written approval. 6. Demo and acceptance ---------------------- 6.1 At each demo the Developer shows completed stories on staging. 6.2 The product owner reports defects against acceptance criteria within [5] business days in one list. 6.3 Defects against criteria are fixed in the next sprint at no extra cost. New ideas go to the backlog under section 9. 6.4 If no defects are reported within the window, the sprint is accepted and its milestone invoice is issued. 7. Bug severity levels ---------------------- Severity | Definition | Response during build | Response during warranty -------- | --------------------------------------------- | ---------------------- | ------------------------ Critical | Production down, data loss or security breach | [4] business hours | [4] business hours High | Core flow broken, no workaround | Next business day | [1] business day Medium | Feature broken, workaround exists | Current or next sprint | [5] business days Low | Cosmetic, copy, minor UI | Backlog | Next scheduled fix batch 8. Repository, licenses and handover ------------------------------------ 8.1 Code is kept in [REPOSITORY HOST] under the Client's organization account from sprint 0. 8.2 Third-party and open-source components are listed in [FILE], with their licenses. No component under a license the Client has rejected ([LIST]) is used without approval. 8.3 Paid third-party services (APIs, hosting, email) are contracted in the Client's name. 8.4 At release the Developer hands over: source code, deployment instructions, environment variable list (without secret values), admin credentials transfer, and a [60]-minute handover call. 8.5 Warranty: [60] days from production release, covering defects against accepted criteria. Excludes new features, changes by others, and changes in third-party services. 9. Change control ----------------- 9.1 New stories are added to the backlog by the product owner and estimated by the Developer within [3] business days. 9.2 A new story can replace a planned story of equal or larger estimate at no fee change. Anything that adds to total effort needs a written change order with the added fee and sprint impact. # | Date | Story added / removed | Estimate impact | Fee impact | Approved by - | ------ | --------------------- | --------------- | ------------------- | ----------- 1 | [DATE] | [DESCRIPTION] | [+N hrs] | [CURRENCY] [AMOUNT] | [NAME] 10. Acceptance -------------- Developer | Client ------------------------------- | ------------------------------- Signature: ____________________ | Signature: ____________________ Name: [NAME], [TITLE] | Name: [NAME], [TITLE] Date: [DATE] | Date: [DATE] ------------------------------------------------------------ How to use this template 1. Write acceptance criteria for every Must story before signing; Should and Could stories can be refined later. 2. Set up the repository and staging in the Client's accounts during sprint 0. 3. Run the demo, then send the acceptance window reminder the same day. 4. Re-estimate the backlog at every sprint planning and log swaps in section 9. Template provided by Colo (trycolo.co). Not legal advice — review with a qualified professional in your jurisdiction.