Skip to main content

What is the difference between a scope and a release?

Short answer: they are the same object seen from two angles. "Release" is the word you see throughout REQQA's interface — the name on the button, the page title, the list heading. "Scope" is the underlying object that a release is built on, and it is the word used in the database, the URLs, and the code. When you create a Release in the app, you are creating a scope record behind the scenes.

So you are never choosing between the two. A release has a scope; the scope is what gives the release its boundary and contents.

Why two words?​

The two words exist because they describe two different things that happen to live in the same record:

  • A release is the deliverable unit — the thing with a name, a status, a lifecycle, a set of stories, a build plan, and a final acceptance. It is how teams actually talk: "what's in the v2 release?"
  • A scope is a property of that release — its contents and its boundary. You use the word naturally in phrases like "the scope of the release", "in scope", and "out of scope". REQQA even has an Out of Scope field on every release, which correctly uses "scope" to mean the boundary, not the release itself.

REQQA originally called the object a "scope" everywhere. During testing it became clear that nobody in a real software team says "a scope" when they mean "a release" — "release" is the standard industry term and maps cleanly onto how people work. Rather than rename the database table, controllers, and URLs (which would break bookmarks and add churn for no user benefit), the team translated only the user-facing layer. So the screen says Release; the code stays scope.

note

This is why you will sometimes see "scope" leak through into a URL — for example, opening a release takes you to a path like /scopeView/..., and the release list lives at /scopesList. The page itself is titled and labelled "Release". That is expected, not a bug.

How the model fits together​

Here is the shape of it, from the top down:

  • An application can have many releases (scopes).
  • A release collects a set of stories — and through those stories, the requirements they belong to. This is the scope of the release: what is in, and (via the Out of Scope and Constraints fields) what is deliberately out.
  • A release moves through a small status lifecycle: Draft, Handover Ready, Release Accepted, and Abandoned. You define and adjust the contents while the release is in Draft; you mark it Handover Ready when the scope is settled.
  • A build plan hangs off the release. Once a release is Handover Ready, a plan can be submitted against it. The plan has its own separate lifecycle (Draft, Approved, In Progress, Paused, Done, Accepted by Customer), so the analyst's view of the release and the builder's view of the build progress never get tangled.

In other words: the release is the container, the scope is its boundary, and the plan is the work that delivers it.

Will I ever need to think about "scope" directly?​

Rarely. In day-to-day use you create, fill, and progress Releases. You will only meet the word "scope" in three harmless places:

  1. The Out of Scope and scope-boundary fields on a release, where it correctly means "the boundary".
  2. A URL or address bar, where scope* paths are the stable code identifiers.
  3. Older project documentation, where "scope" was once used as the object name.

None of these change anything you do. Treat "release" as the thing and "scope" as one of its properties, and the terminology will stay out of your way.

  • Releases and scopes — the full conceptual chapter, including the status lifecycle and how plans attach.
  • How to manage releases — the step-by-step recipe for creating a release and defining its scope.
  • Key concepts — how releases sit alongside requirements, stories, and applications.