This week I want to talk about how we use the word "scope" in a software project.
Broadly speaking, scope refers to the list of requirements that the software is expected to fulfill. Sometimes it's a literal list of feature requirements, user stories, or some other form of functionality description.
Many projects begin with a "scope document" that enumerates every specific function the software will be expected to perform. Others take a fuzzier approach, focusing on high-level goals rather than detailed requirements (which are rarely correct at the start of a project anyway).
Scope documents are important to both the developer and researcher. For the researcher, it serves as a basic agreement of the work to be done. Sometimes the scope document is called a "Statement of Work" for that reason.
For the developer, the scope document draws a clear boundary between the work that is to be done by the developer, and the work that is specifically not to be done. It's a map. Conversations about functions inside the boundary will result in work to be done; otherwise it's a discussion that the developer can safely ignore.
But (you knew this was coming): it's a trap! The scope document is the first thing to be pulled out during a disagreement about whether or not the software is "done."
It's used has a weapon when the developer claims something can't or won't be delivered because it is "out of scope."
It can easily become a source of frustration and cover-your-butt techniques for each side, rather than the thing it was truly meant to be: a clear description of the outcome we want at the end.
Now, this is a big topic that probably deserves a second issue, but my recommendation is as follows:
Pay for outcomes. Don't pay for scope.