HKSM

Unapproved Change Requests are formally submitted proposals to modify scope, requirements, or deliverables that have not yet been analyzed or authorized by the Product Owner or change authority. They are captured in a change log or as placeholder backlog items and must not be acted on by the Scrum Team until a decision is made.

Key Points

• Represents pending change proposals that are logged but not yet authorized for implementation.
• Typically originates from stakeholders, the Scrum Team, Sprint Reviews, defect discovery, risk responses, or compliance needs.
• Serves as an input to the Manage Changes support process; outcomes become Approved or Rejected Change Requests.
• Must not alter Sprint scope unless the Product Owner approves and, if necessary, re-plans or cancels the Sprint.
• Requires impact analysis on value, scope, cost, schedule, quality, risk, and acceptance criteria.
• Links to Product Backlog grooming and release planning once a decision is made.

Purpose

To provide a controlled, transparent holding area for proposed changes until they are analyzed and decided. This protects the Sprint timebox, preserves team focus, and ensures that only value-adding changes enter the Product Backlog.

It also supports organizational governance by documenting requests and decisions, keeping a clear audit trail across Sprints and releases.

Key Terms & Clauses

• Change Log: A single list where change requests are recorded, tracked, and updated.
• Product Owner (PO): Primary change authority for scope and priority decisions; may escalate per governance.
• Change Authority/CCB: An enterprise body used when policy requires formal approval beyond the PO.
• Impact Analysis: Collaborative assessment of value, effort, cost, schedule, quality, dependencies, and risk.
• Prioritized Product Backlog: Destination for approved changes, expressed as epics or user stories with acceptance criteria.
• Timebox Policy: No mid-Sprint scope change without explicit approval and re-planning by the PO.

How to Develop/Evaluate

1. Capture: Log the request with title, requester, problem/opportunity statement, proposed change, and expected value.
2. Triage: Check for duplicates, clarify intent, and classify (defect, enhancement, regulatory, technical debt).
3. Analyze: With the Scrum Team, perform quick impact analysis, identify dependencies, and produce a high-level estimate.
4. Decide: The PO (or change authority) approves, rejects, or defers pending more information.
5. Translate: For approvals, create or update epics/user stories with acceptance criteria and initial priority.
6. Record: Update the change log status and communicate the decision to stakeholders.

How to Use

• As an input to Manage Changes to drive analysis and decision-making before any work starts.
• Feed approved items into Groom Prioritized Product Backlog for sizing, ordering, and story refinement.
• Update Release Planning to reflect scope, schedule, and funding impacts of approved changes.
• If urgent and high value, the PO may re-plan or cancel the Sprint; otherwise, defer to a future Sprint.
• Maintain traceability by linking each request to resulting backlog items, test cases, and Definition of Done updates.

Example Snippet

Example change log entry:

• ID: CR-018.
• Title: Add two-factor authentication to login.
• Source: Security officer (stakeholder).
• Rationale: Compliance requirement; reduces risk exposure.
• Impact (initial): Medium effort; affects login, user settings, and testing scope.
• Status: Unapproved – awaiting PO decision after team estimation.
• Next Action: Discuss in Manage Changes session; create epic and stories if approved.

Risks & Tips

• Risk: Scope creep through informal changes. Tip: Enforce the rule that no unapproved change can alter Sprint scope.
• Risk: Decision latency creates backlog bloat. Tip: Set a service-level goal (e.g., triage within 48 hours).
• Risk: Misalignment with product vision. Tip: Require a clear value statement and ROI rationale for each request.
• Risk: Regulatory gaps if escalations are skipped. Tip: Escalate to the CCB when governance demands formal approval.
• Risk: Hidden technical impacts. Tip: Include architects/developers in impact analysis and capture dependencies.

PMP/SCRUM Example Question

A stakeholder submits a request mid-Sprint to add a new compliance report. The Scrum Team can estimate it quickly, but it is not yet approved. What should the Scrum Master advise?

1. Start implementing it to avoid delays, and seek approval afterward.
2. Add it to the current Sprint Backlog as a stretch goal without changing scope.
3. Record it, perform impact analysis with the team, and have the Product Owner decide; do not implement until approved.
4. Reject all mid-Sprint change requests to protect the timebox.

Correct Answer: C — Record it, analyze impact, and wait for the Product Owner's decision before any implementation.

Explanation: Unapproved Change Requests are input to Manage Changes and must not alter Sprint scope until the PO authorizes. Options A and B bypass approval; D is overly rigid and ignores valid requests.