Defining Project Scope: What’s In, What’s Out
Software teams often complain about scope creep. But how do you even represent scope on a software project?
Every software team talks about scope, and project team members often complain about unending scope creep. Unfortunately, the software industry lacks a uniform definition of these terms, and the requirements engineering literature lacks clear guidance on how to represent scope. This article presents some definitions and describes several techniques for defining scope on software projects.
What Is Scope?
We can define scope as a set of capabilities that stakeholders agree to be delivered in a specific iteration, build, or product release. Scope defines the boundary between what’s in and what’s out for a body of work. When a project manager agrees that their team will deliver a specific set of functionality at a particular quality level by a particular date, they’ve established the scope of that delivery. When a product owner commits to implementing a particular set of user stories in a development increment or sprint, they’ve defined the scope of that increment.
The scope for any portion of the project represents a subset of the ultimate product vision, a stepping stone on the pathway from project…
