HKSM

Approved Change Requests are documented change proposals that the Product Owner or designated governance body has formally accepted for implementation. They trigger updates to backlog items, plans, or standards and are traceable to business value and impact. In SBOK, they act as inputs and outputs across change-related Scrum processes.

Key Points

• Formal, recorded decisions to proceed with a change that affects scope, priority, acceptance criteria, process, or standards.
• Authorized primarily by the Product Owner for product changes, or by a required governance board if mandated.
• Flow into updates of the Prioritized Product Backlog, Sprint Backlog, Definition of Done, release plan, and related logs.
• Contain clear rationale, impact summary, acceptance criteria, and implementation guidance.
• Enable controlled adaptability by filtering ideas through value and impact before they enter delivery.
• Mid-sprint changes are negotiated to protect the Sprint Goal, with major changes usually deferred.
• Tracked end-to-end for auditability, from request to deployment and validation.

Purpose

Ensure only vetted, valuable changes enter the delivery workflow, maintaining transparency and control. Provide a single source of truth for what was approved, why, and how it will be implemented.

Connect decision-making to execution by linking approvals to specific backlog updates, sprints, and acceptance criteria. Support compliance, quality, and traceability throughout releases.

Key Terms & Clauses

• Approval Authority: Product Owner for product scope and priorities; governance board only where organizational policy demands it.
• Change Record: ID, description, requester, business value, impact (scope, schedule, cost, risk), affected user stories or epics, decision (approved, deferred, rejected), effective sprint or release.
• Acceptance Criteria Update: When a change alters conditions of satisfaction, the criteria are revised and documented.
• Definition of Done Update: Quality or compliance changes may update the team’s DoD.
• Emergency Change Clause: Critical defects or regulatory fixes may be implemented mid-sprint by agreement if the Sprint Goal remains safe.
• Timebox Protection: Significant changes are typically scheduled for a future sprint to avoid churn.

How to Develop/Evaluate

1. Capture: Log the request with context, value hypothesis, and initial scope.
2. Triage: Scrum Master and Product Owner screen for completeness and urgency.
3. Impact Analysis: Scrum Team estimates effort, risks, dependencies, and potential schedule effects.
4. Value Assessment: Product Owner weighs business value, customer impact, and strategic alignment.
5. Decision: Approve, defer, or reject; record the rationale and any constraints or conditions.
6. Traceability: Link the approved request to updated user stories, epics, DoD items, and release or sprint plans.
7. Communication: Share the decision and next steps with stakeholders and the team.

How to Use

• Backlog Refinement: Convert approvals into new or updated user stories with prioritized ordering and acceptance criteria.
• Sprint Planning: Decide whether to pull the changed items into the next sprint; negotiate scope if an urgent change must enter mid-sprint.
• Tasking: Break approved changes into tasks and update the Sprint Backlog and Scrumboard.
• Quality Integration: Update the Definition of Done or test strategy if the change impacts quality standards.
• Release Planning: Reassess release scope and timelines if the change affects delivery dates or dependencies.
• Validation: During Sprint Review, demonstrate changed functionality and confirm acceptance criteria are met.

Example Snippet

A stakeholder requests enhanced audit logging. The Product Owner logs it, the team estimates impact, and it is approved due to compliance needs. The change is captured as a new user story linked to an existing epic, prioritized above similar items, and scheduled for the next sprint.

The DoD is updated to include audit logging for any feature touching customer data. At Sprint Review, the team demonstrates the logs and the Product Owner accepts the story against the revised criteria.

Risks & Tips

• Risk of scope creep if approvals bypass impact analysis; always involve the team for sizing.
• Disruption from mid-sprint changes; protect the Sprint Goal and defer large changes when possible.
• Unclear change records cause rework; require explicit acceptance criteria and rationale.
• Governance bottlenecks slow delivery; clarify who approves what and set service-level expectations.
• Tracking gaps reduce traceability; link every approved request to backlog items and releases.
• Use a lightweight template so decisions are fast yet complete.

PMP/SCRUM Example Question

A change to strengthen security headers is approved during release planning. What should the Scrum Master and Product Owner update first to reflect this Approved Change Request?

1. The Sprint burndown chart for the current sprint.
2. The Prioritized Product Backlog with new or updated user stories.
3. The team’s working agreement to include security rules.
4. The release burndown to show an immediate scope increase.

Correct Answer: B — The Prioritized Product Backlog with new or updated user stories.

Explanation: Approved changes are incorporated into the Prioritized Product Backlog first so they can be refined, prioritized, and then planned into a sprint. Other artifacts update later as work is scheduled and executed.