Glossary
Scope creep
Scope creep is the gradual growth of a project beyond what was agreed, as new features and changes are added along the way without adjusting the budget, the timeline or the priorities to match.
An example of scope creep
A company agrees to build a simple order-tracking portal. During the build, someone asks for customer chat, then a mobile app, then a link to a second warehouse. Each request sounds small. Together they double the work, push the launch back and leave the original goal half-finished.
Why does scope creep happen?
- The goal and the first release were never written down clearly.
- New stakeholders join the project with their own wishes.
- Nobody asks what will be dropped or delayed to make room for a new request.
- Users see the software for the first time and realise what they really need.
How to avoid scope creep
- Write a short scope for the first release and agree it before the build starts.
- Keep a “later” list so good ideas are captured without being built now.
- Treat each new request as a trade: something moves out, or more time and budget move in.
- Review working software often, so surprises appear early.
Frequently asked questions
Is all scope change bad?
No. Changing course because real users showed you something new is healthy. It becomes scope creep when changes pile up without anyone deciding the trade-off in time, money or other features.
Who is responsible for controlling scope creep?
Both sides. The client sets the priorities, and the development team should flag the cost of each change before doing it. A clear written scope makes those conversations much easier.