Template by Industry / Domain

Software Project Charter Template: Scope, Tech Debt, NFRs, and Definition of Done

Software charters are not generic charters with "software" in the title. They have explicit codebase boundaries, named tech-debt budget, NFRs, environment strategy, and rollback criteria. The sections most often skipped are also the sections most often catastrophic at launch.

What Makes a Software Charter Different

A generic PMBOK charter assumes the project produces a tangible deliverable on a defined schedule, with risk concentrated in budget overruns and resource availability. Software risk is concentrated in different places: codebase entropy, non-functional requirements (latency, security, accessibility) that are invisible until they fail, integration with services owned by other teams, and the rollback path when something breaks at 02:00 on launch night.

The six sections below adapt or add to the PMBOK base. They are drawn from common patterns in Atlassian's Agile project management guidance, the IEEE SWEBOK, and the DORA / Accelerate research on high-performing software organisations.

Six Sections Specific to Software Charters

1. Codebase Scope

Which repos, services, or modules are in scope and which are not. The most-skipped section. Without it, the team accepts every reasonable-sounding request that touches adjacent code.

Example: In: payments-service, payments-api-gateway. Out: ledger-service (separate cohort), reporting (no changes).

2. Tech-Debt Budget

How much of the team's Sprint capacity is reserved for paying down existing debt vs delivering new functionality. Should be a percentage, named upfront.

Example: 20% of every Sprint reserved for debt reduction; tracked separately in the burndown.

3. Non-Functional Requirements (NFRs)

Performance, security, accessibility, observability, and reliability targets. Frequently invisible at charter time and then catastrophic at launch.

Example: P95 latency under 250 ms; 99.95% uptime; WCAG 2.2 AA on user-facing pages; PCI-DSS 4.0 compliant by go-live.

4. Environment Strategy

How many environments (dev, staging, pre-prod, prod), data refresh cadence, and feature-flag strategy.

Example: Four environments. Pre-prod refreshed from prod weekly (scrubbed). LaunchDarkly for all new endpoints.

5. Rollback and Failure Criteria

The conditions under which the team must roll back, and who has the authority to call it. Often missed until the first incident.

Example: Auto-rollback on error rate above 0.5% or P95 latency above 800 ms for 5 consecutive minutes. SRE on-call has authority to roll back without escalation.

6. Dependencies and Integrations

Upstream services the project depends on, downstream consumers, and the SLAs each side commits to.

Example: Depends on identity-service (99.95% uptime SLA). Consumed by fulfillment-service (must maintain v2 API contract).

Filled Example: Payments Service Rewrite

Real-shape worked example for a B2C commerce payments service. Numbers reflect typical mid-size payments rewrites; PCI-DSS and uptime targets reflect public SLAs from large processors.

Project Name and Product Goal

Payments Service Rewrite (Aurora Commerce)

Replace the legacy payments service (PHP 7.4 monolith, last refactored 2019) with a Go-based service that supports the 4 new payment methods needed for European expansion, reduces P95 latency from 740 ms to under 250 ms, and reaches 99.95% uptime.

Duration

9 months (1 Jun 2026 to 28 Feb 2027), 9 two-week Sprints in Build, 4 weeks Discovery, 4 weeks Hypercare

Budget

USD 1.8M loaded team cost plus USD 240K for vendor integrations, observability tooling, and pen test

Team

8 FTE (1 PM, 1 PO, 1 Tech Lead, 4 backend engineers, 1 SRE) plus 0.5 FTE Security Architect and 0.25 FTE Compliance Officer for PCI-DSS oversight

Codebase Scope (In)

  • Rewrite of payments-service in Go 1.22, deployed on existing Kubernetes platform.
  • Migration of 4 existing payment methods (Visa, Mastercard, ACH, Apple Pay).
  • Addition of 4 new payment methods for European expansion (SEPA Direct Debit, iDEAL, Bancontact, BLIK).
  • PCI-DSS 4.0 compliance re-certification.
  • Full re-instrumentation: OpenTelemetry traces, structured logs, RED metrics dashboard.

Codebase Scope (Out)

  • Do not migrate the merchant onboarding service (separate roadmap item).
  • Do not change the existing v2 API contract (consumer compatibility must be preserved).
  • Do not migrate historical transactions (read-only legacy DB retained for 7 years per regulatory requirement).
  • Do not add real-time fraud detection (Phase 2 cohort).
  • Do not migrate retired payment methods (PayPal Express Checkout, sunset Q1 2027 anyway).

Non-Functional Requirements

  • Availability: 99.95% measured monthly (allows 21.6 minutes downtime per month).
  • Latency: P95 under 250 ms for tokenisation calls, P95 under 600 ms for end-to-end transaction.
  • Throughput: 8,000 transactions per minute sustained during peak (Black Friday 13:00-15:00 UTC).
  • Security: PCI-DSS 4.0 Level 1; pen test pass with no critical findings; SAST and DAST in CI pipeline.
  • Observability: 100% of requests traced; 4-week trace retention; alerts on error rate above 0.5% for 5+ minutes.
  • Compliance: GDPR Article 17 right-to-erasure honoured within 30 days for any customer record.

Rollback Criteria

Blue-green deployment with 10-minute health check. Auto-rollback to previous version if any of: error rate above 0.5% for 5 consecutive minutes, P95 latency above 800 ms for 5 minutes, or any unhandled PCI-DSS audit log gap. SRE on-call has unilateral authority to roll back. Sponsor approval required only for the post-rollback decision on whether to retry or pause the migration.

Definition of Done (Appendix B)

  • Code reviewed by at least 1 engineer and 1 SRE or Security Architect.
  • Unit + integration test coverage on changed code at or above 85%.
  • Performance test passes against P95 latency target.
  • Security scan (SAST + DAST + dependency check) returns no Critical or High findings.
  • Observability: traces, metrics, and logs visible in Honeycomb / Grafana before merge.
  • Runbook updated and reviewed by SRE on-call.
  • Customer-facing change: changelog entry drafted; merchant-facing change: docs updated.

Frequently Asked Questions

How does a software project charter differ from a generic PMBOK charter?
Three sections are added or substantially expanded: codebase scope (which repos, services, modules), non-functional requirements (performance, security, accessibility), and rollback / failure criteria. Three sections are condensed: budget is denominated in Sprints rather than line-item costs, milestones are release goals rather than phase gates, and the RACI is smaller because software teams typically have fewer external decision-makers than infrastructure or capital projects.
Why does the charter need to define tech-debt budget upfront?
If the tech-debt percentage is not explicit in the charter, every Sprint becomes an argument between the PO who wants feature delivery and the engineers who can see the debt growing. The healthy organisations make the trade-off explicit at charter time, usually 15-25% of Sprint capacity reserved for debt reduction. The Atlassian engineering blog and the State of DevOps research (DORA team) both consistently link explicit debt budgets to higher delivery velocity over a 12-month horizon.
Should the charter list all non-functional requirements or just the headline ones?
All categories should be named, but only the headline targets need to be in the charter. The detailed NFR catalogue typically lives in a separate document (often the API spec or the architectural decision records). The charter version is a list of NFR categories with one or two leading numeric targets per category, plus a reference to the detailed document.
How does the charter handle a microservices vs monolith decision?
The decision should sit in the architectural approach section, not be left implicit. If the charter does not state 'this will be a microservice extracted from the monolith over Sprint 3-5', the team will discover the architectural decision halfway through Build and either fight about it or arrive at a worse choice. Atlassian's microservices guide recommends explicit ADR-style decisions for any architecture choice that affects more than one team.
What is the right Definition of Done for a software project charter?
The charter references the DoD by saying 'Definition of Done is authored by the Scrum team in Sprint 0 and reviewed at every retrospective; current version is appendix B'. Specific DoD content depends on the team but always includes: code review, automated test coverage threshold, security scan pass, observability instrumentation, and runbook update. The DORA capability research shows the strongest predictor of low-defect-rate teams is a Definition of Done that includes automated test coverage above 80% and automated security scanning.
How should a software charter handle vendor and SaaS dependencies?
Name each external dependency with the SLA it commits to, the integration pattern (sync vs async, retry strategy, circuit breaker), and the failure mode if the dependency is down. If the project depends on a SaaS with an SLA below the project's own uptime target, the gap should be acknowledged in the charter and the mitigation (caching, queue-and-retry, graceful degradation) named. The most common software project failure is 'our 99.95% target depends on a vendor offering 99.5%' nobody flagged at charter time.
Does a software project charter need a compliance section?
Yes if the project touches regulated data: PCI-DSS for payments, HIPAA for health, GDPR for EU personal data, SOC 2 if the company holds enterprise customer trust certifications. The charter should name each applicable regime, the current compliance posture, the certification or audit timeline, and the named compliance owner. If the project is entirely non-regulated, a one-sentence statement to that effect ('no PCI / HIPAA / GDPR data in scope, no audit requirements') prevents the question being asked repeatedly.

Related on this site

Scrum charter (Sprint cadence and DoD)Agile charter overviewIT / ERP migration charterHybrid waterfall-agile charterRisk matrixScope boundaries guide

Updated 2 May 2026