Build fluency in the language used to recognize and manage scope creep.
0 / 5 completed
1 / 5
At standup, a dev notices a small bug fix has grown into a much larger refactor mid-implementation. What is this phenomenon called?
Scope creep describes the gradual, often unapproved expansion of a task's boundaries beyond what was originally planned, typically without corresponding adjustments to timeline or resources. It commonly starts small and compounds over the course of implementation. Recognizing it early helps a team decide whether to expand scope deliberately or defer the extra work.
2 / 5
During a design review, the team explicitly lists what the project will and will not address. What is this list called?
Defining explicit scope boundaries, both what's in scope and what's explicitly out of scope, gives the team a reference point to push back against creeping additions during implementation. Without this, "just one more small thing" requests are harder to evaluate objectively. It's a preventive tool against scope creep, not just a retrospective label.
3 / 5
In a code review, a dev flags that a PR includes unrelated changes beyond the original ticket. What should the reviewer suggest?
When a PR balloons beyond its original ticket's scope, reviewers commonly suggest splitting unrelated changes into a separate, focused PR. This keeps each change reviewable and revertible independently. It is a practical, PR-level defense against scope creep accumulating in a single change.
4 / 5
An incident report shows a deadline was missed because new requirements kept being added mid-sprint without renegotiating the timeline. What governance gap does this reveal?
Without a change-control process requiring new requirements to be evaluated against timeline and resourcing impact, scope can silently expand and derail deadlines. Establishing that any addition triggers a conversation about tradeoffs prevents this drift. This is a common root cause identified after missed deadlines.
5 / 5
During a PR review, a teammate proposes adding "just one more small feature" before merging. What question should the team ask first?
Before accepting an unplanned addition, the team should check whether it falls within the already-agreed scope, or whether it constitutes new work that deserves its own planning and prioritization. Reflexively saying yes to "just one more thing" is exactly how scope creep accumulates. Asking this question preserves intentional, deliberate scope decisions.