- Description
- Carte ancienne gravée de la Guyane et du lac Parime, désigné comme la route de l'Eldorado.
- Source
- Willem Blaeu · original page
- Licence
- PD Public domain
Scope and Requirements Management (PER)
Scope is the boundary between what we committed to deliver and everything else. Projects rarely drift because of one big decision; they drift through the buildup of “small additions…
Level: 🟢→🔴 · Code: PER · Matrix: PI
Why this theme#
Scope is the boundary between what we committed to deliver and everything else. Projects rarely drift because of one big decision; they drift through the buildup of “small no-impact additions” that, combined, double the workload. Conversely, a rigidly fixed scope delivers a solution that matches a need that has changed. A mature theme does not choose between rigidity and laxity: it makes change visible, governed, and quantified.
What this theme measures#
- Axis: from informal requests to value-driven scope management.
- Key indicator: scope drift rate (undecided added workload / initial workload), share of requests handled through a tracked process.
- Unit: % drift; number of requests handled outside process; decision lead time for a change request.
The five levels#
| Level | Short name | Promise | Typical indicator (orders of magnitude) |
|---|---|---|---|
| 1 | By email | Requests come in through every channel; we try to do everything. | Unmeasured drift; > 50% undecided additions |
| 2 | Request list | All requests are in one place; we know what is being requested and by whom. | 70 to 90% of requests tracked |
| 3 | Prioritized backlog | Requirements are described, ordered by value, and every change goes through tracked governance. | ≥ 95% tracked; decision < 1 week |
| 4 | Measured drift | Drift is monitored, each addition is quantified in cost and schedule before acceptance; requirements are traceable up to acceptance testing. | Undecided drift < 10%; traceability ≥ 90% |
| 5 | Value-driven | Scope is a lever: we remove what no longer delivers value, deliver the minimum useful scope, and measure actual usage of delivered features. | Unused features < 20%; usage measured by feature |
Milestones by level#
| ID | Milestone | Verifiable evidence |
|---|---|---|
| PI-PER-1.1 | A description of the expected product exists (even minimal). | Document or root ticket. |
| PI-PER-1.2 | Requesters are identifiable. | Requester recorded on 90% of recent requests. |
| PI-PER-1.3 | Rejecting or postponing a request is possible. | Example of a postponed request. |
| PI-PER-2.1 | All requests are in a single tool. | No “out-of-tool” request over one month. |
| PI-PER-2.2 | Each request has a status (new, accepted, rejected, delivered). | Status column filled in. |
| PI-PER-2.3 | Scope is compared with the scoping baseline at each milestone. | Scope mentioned in reviews. |
| PI-PER-3.1 | A single backlog is ordered by a known prioritization rule. | Rule written down; order verifiable. |
| PI-PER-3.2 | Requirements are written in a verifiable way (acceptance criteria, examples). | 10 selected items: testable criteria. |
| PI-PER-3.3 | Every change request follows a process: assessment, governance decision, trace. | Change log with decisions. |
| PI-PER-3.4 | Definition of Ready (or equivalent) prevents starting vague requirements. | Entry criteria applied. |
| PI-PER-4.1 | The impact (workload, schedule, risk) of each change is quantified before decision. | Impact sheet for 5 changes. |
| PI-PER-4.2 | Scope drift is measured and reported to the steering committee. | Drift indicator at each review. |
| PI-PER-4.3 | Traceability requirement → development → test → delivery. | Reconstructable chain for 5 requirements. |
| PI-PER-4.4 | Obsolete requirements are explicitly removed. | Closed “abandoned” items with reason. |
| PI-PER-5.1 | Actual usage of delivered features is measured (telemetry, logs, viewed reports). | Usage dashboard by feature or report. |
| PI-PER-5.2 | Low-usage features are removed or simplified. | At least one documented removal in the year. |
| PI-PER-5.3 | Scope is split into minimal value slices (incremental delivery). | Successive releases with identifiable value. |
| PI-PER-5.4 | The sponsor arbitrates on value: “adding X means removing Y.” | Tracked trade-off decisions. |
Detailed reading by level#
Level 1. Signs: hallway requests, email, messaging; the team gives in to avoid conflict. Benefit: fast intake. Does not guarantee: consistency, or the ability to finish. Difficulty: 1/5. Effort: 1/5.
Level 2. Signs: a single list; we can answer “where is my request at?”. Benefit: end of lost requests. Does not guarantee: priority order or workload impact. Difficulty: 2/5. Effort: 1/5.
Level 3. Signs: an ordered backlog; the prioritization rule is openly discussed; changes do not come in “through the back door.” Benefit: team stability, understandable priorities. Does not guarantee requirements are correct. Difficulty: 3/5. Effort: 2/5.
Level 4. Signs: impact sheet per change; drift indicator. Benefit: the sponsor decides with full information. Does not guarantee the scope delivers value. Difficulty: 4/5. Effort: 3/5.
Level 5. Signs: feature removals, measured usage, sliced delivery. Benefit: focus on what matters, reduced functional debt. Does not guarantee the right product strategy. Difficulty: 5/5. Effort: 4/5.
Partial achievement and rating#
Common rule: see README.
- 0.5: ordered backlog but implicit prioritization rule; change process reserved for large changes.
- 1: the practice is visible on 5 randomly selected items.
- A partial 5: report usage measured (via service logs) and one feature removal last year, but no telemetry across all scopes. Score ≈ 4.4.
Power BI sales force reports: out of 60 delivered reports, usage logs show that 18 have not been opened in 6 months. Decision: remove 12, merge 6. Benefit: maintenance and acceptance testing workload reduced by about one third (order of magnitude for this fictional example).
Backlog graveyard. Symptom: 800 items, half over one year old; prioritization becomes fictional. Cause: nothing is ever removed. Remedy: maximum lifetime, quarterly purge, closure with reason.
Goodhart: with “zero untracked changes” as a goal, requests are split to stay below the process threshold (salami slicing). Monitor the total of small changes by theme.
In a data project, functional requirements hide data requirements (history, freshness, granularity) that weigh more than screens; see Scoping, Value, and Use Cases.
Move to the next level#
Possible means (optional)
- 1 → 2: a single intake channel (form, ticket inbox), simple statuses.
- 2 → 3: backlog with prioritization rule (value, risk, cost of delay), acceptance criteria, lightweight change committee; see Scrum in Practice and fundamentals.
- 3 → 4: impact sheet, links between work items in Azure DevOps / TFS, drift indicator.
- 4 → 5: usage telemetry, quarterly usefulness review, sliced delivery (Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…)).
AI rephrases ambiguous requirements, generates candidate acceptance criteria, and detects contradictions between requests; it does not know which requirements have value for your users, and generated “plausible” but unvalidated criteria create false precision.
See also#
- Related themes: 01 Scoping · 03 Planning · 08 Quality and Acceptance · 11 Budget and Value.
- Other matrices: Documentation and Knowledge Transfer (DL) · UAT and Business Validation (data) · Visualization and UX (BI).
- In practice: Project Management Fundamentals · Scrum in Practice · Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…) · Project Planning and Tracking Tools: Overview · Glossary.
✻ Written by Claude Sonnet 5.5
