The scope statement was signed in week one. Section 3, “Out of scope,” lists five items. Item 4 reads “Bulk export to CSV — deferred to a later release.” In week five, a sales lead asks for “just the basic export” for one customer. It is two stories. Nobody opens the scope statement, because nobody thinks of two stories as a scope change. The document still says item 4 is out. The Fix Version says it is in.

Nothing went wrong with the people or the document. The scope statement did what it was built to do. It just was not built to notice.

What a scope statement is good at

A project scope statement describes the boundary of the work. The usual sections are a scope description, deliverables, acceptance criteria, exclusions, constraints and assumptions. With the work breakdown structure, it forms what PMI calls the scope baseline.

Writing one forces the hard conversations early. The exclusions list is often the most valuable part: it records what the team deliberately said no to, and why. That is expert engineering judgment, and it is the same judgment the team brings to the confidence vote. When a team votes a four or a five on a release, it is voting on the scope described in that statement.

What it cannot tell you

A scope statement describes a boundary. It holds no throughput, no capacity and no sequencing, so it cannot say when the work inside the boundary will finish. That was settled in the vote.

After the vote, the statement has two structural limits. First, it is revised only through change control, so it changes when someone files a change request. Second, it records the boundary, not the traffic across it. Scope that crosses without paperwork leaves the statement exactly as it was signed, while the committed date moves underneath it.

How scope crosses the line without a change request

Scope creep is the first of the three things that erode a committed release date, and it rarely announces itself. In practice it enters through three doors:

• Small additions. Each one is too small for the change control board. Together they are a sprint.
• Re-included exclusions. An item from the “out of scope” list returns as “just the basic version.”
• Growth inside existing items. Acceptance criteria expand after refinement. The item count stays the same; the work does not.

The assumptions section carries the other two killers. “Platform API available by sprint 3” is a dependency. “Team of six throughout” is a capacity assumption. When either stops being true, the statement does not change, but the date does.

Point the boundary at the Fix Version

Keep the scope statement. Change what its in-scope list points at. Instead of copying a list of deliverables into the document, reference the Jira Fix Version as the live boundary. Then open every review with one number: the gap between the committed date and today’s forecast at the confidence level the team committed at.

An illustration: a team commits to 6 November at 85% confidence. By week five, the two export stories and three expanded acceptance criteria have landed in the Fix Version. The scope statement is unchanged. The forecast at 85% now reads 13 November. The gap is seven days. The conversation moves from “is this in scope?” to “which item comes out, or which date do we renegotiate, to recover seven days?”

How Advanced Release Planning keeps it live

Advanced Release Planning for Jira does not write, store or template your scope statement. The team still owns the assumptions: which throughput window to trust, whose capacity is in, what is in scope. The app does the arithmetic at Monte Carlo scale over the team’s real Jira throughput and keeps it current.

• The committed date carries a live confidence band: 50%, 85% and 95%.
• Items added to the Fix Version step up the burn-up scope line and move the forecast. Scope growth is reported as a percentage and a per-day rate; removals step the line back down.
• A MoSCoW cut-line marks which items are expected to ship and which are at risk.
• Dependencies are read from Jira links, and capacity changes flow into available throughput, so the assumptions section has a live counterpart.

A section-by-section mapping is in the Scope Statement & the Committed Release Date reference.

The scope statement records where the team drew the line. The forecast shows what crossing it has cost. With both, the team renegotiates before the date slips, not after.

FAQ

What should a project scope statement include?

A scope description, deliverables, acceptance criteria, explicit exclusions, constraints and assumptions. For a release, add the committed date with the confidence level it was committed at, and a reference to the Fix Version that holds the live scope.

Is a scope statement the same as a statement of work?

No. A statement of work is a contractual document between parties. A scope statement is the project team’s description of the boundary of the work, and it can exist with or without a contract.

See your committed date and its live confidence band in Advanced Release Planning, or view it on the Atlassian Marketplace.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio