Lesson 2 · about 12 minutes

In or out?

A project needs an end. It also needs edges: what it does, and what it does not do. Without edges, a project grows until it never ends.

Your win today

You write the edges of a feature: what is in, and what is out. And when new work shows up halfway, you ask the one question that saves the date: “What do we drop for it?”

0. Warm-up from Lesson 1

No peeking.

Type the two features that make work a project.

Temporary (it has an end) and unique (it makes something new). Today: how to keep that end reachable.

1. Scope: the edges of a project

“Project scope planning is concerned with defining all the work needed to meet the project objectives successfully.” — Oguz, 4.4 Project Scope Management

The scope of a project is all the work needed to reach its goal. Lesson 1 gave you the goal: “Done when …”. Scope is the work that gets you there.

“We should also define what is not included in the project’s scope.” Oguz’s example: “Smartphones with operating systems other than Android and IOS are excluded.” — Oguz, 4.4.1

A scope has two sides. What is in. And what is out of scope: the work this project will not do. Here is the export from Lesson 1, with its edges:

Scope: new export for authorities
Done when	Authorities can download the new export from the app, before the next bat season.
In	The export file in the format the authorities ask for. A download button on the report page. A test with the data of one real wind farm.
Out	A PDF version. Changes to the old export. Formats for other authorities.

2. The most useful line: “Out”

Shape Up calls these “no-gos”: “if there’s anything we’re not doing in this concept, it’s good to mention it here.” Its example: “WYSIWYG might be better in some peoples’ eyes, but given the appetite it was important to mark this as a no-go.” — Ryan Singer, Shape Up, ch. 6

The “Out” list is short, but it does a lot of work. It stops surprises.

A good “Out” line names something that people would expect. Nobody expects a game, so “Out: a game” says nothing. Many users expect a PDF. “Out: a PDF version” stops a fight before it starts.

3. Scope creep

Scope creep: “continuous or uncontrolled growth in a project’s scope, generally experienced after the project begins.” — Wikipedia, “Scope creep”, after J. P. Lewis, Fundamentals of Project Management

Scope grows. Rarely in one big step. Usually in many small, friendly requests: “While you are at it, can it also …?” Each one is small. Together they eat the date.

When scope grows and nobody decides it, that is scope creep.

“Scope grows naturally. Scope creep isn’t the fault of bad clients, bad managers, or bad programmers.” — Shape Up, ch. 14

The problem is not the change. Change is normal: you learn things during a project. The problem is that nobody decided. Nobody checked what it costs, and the plan stayed the same.

“Change control is a set of procedures that let us make changes in an organized way.” — Oguz, 11.4 Change Control Process

Scope creep	Scope change
Nobody decides it.	It is decided in the open.
The plan stays the same.	The plan changes too: more time, or other work goes out.
You find it late, when the date slips.	Everyone knows at once.

4. Fixed time, variable scope

“This principle, called ‘fixed time, variable scope,’ is key to successfully defining and shipping projects.” And: “When you have a deadline, all of a sudden you have to make decisions.” — Shape Up, ch. 3

Shape Up is the way the software company Basecamp runs its projects. It has a simple rule against creep: fixed time, variable scope. The date stays. The scope bends.

For this, split the “In” list in two:

must-have: without it, “done when” is not true.
nice-to-have: good, but the goal is reached without it.

Nice-to-haves are “things to do if the team has extra time at the end and things to cut if they don’t.” — Shape Up, ch. 14

The test: take the item away. Is “done when” still true? Then it is a nice-to-have.

Now new work cannot just slip in. It must push something out. So when new work shows up, you ask: “What do we drop for it?”

The box is the time, and it does not grow. When a new request comes in, something else must go out. Nice-to-haves go first.

You do not need to be the lead to ask this question. It is a question, not a decision. The lead decides. Your question makes sure that somebody does.

5. Practice

All questions use the export scope from part 1.

Week 2. A user asks: “Can the new export also come as a PDF?” What is the best answer?

PDF is on the “Out” list, so the answer is already there: not now. “Only one day” is how creep starts. And moving the date for out-of-scope work is the wrong way round. Shape Up’s friendly default: “Interesting. Maybe some day.” (ch. 3)

You write the “Out” list for a new feature. Which line is the most useful?

A good “Out” line names something that people would expect. Many users expect a PDF, so this line stops a surprise. Nobody expects a game. And “all work not listed” is true, but it tells nobody anything.

Week 3. A tester says: “While you are at it, can the export also sort by turbine?” The developer adds it the same day. Nobody else hears about it. What makes this scope creep?

The work is small, and anyone may ask. It is creep because the scope grew and nobody decided: nobody checked the date, and nobody else knows. “Scope grows naturally. Scope creep isn’t the fault of bad clients, bad managers, or bad programmers.” (Shape Up, ch. 14)

The export must be ready before the bat season. That date is fixed. In week 4 the team sees: not all the planned work fits. With “fixed time, variable scope”, what happens?

The time is fixed, so the scope bends. A later date breaks the rule. Longer days break it too: the time grows, only at night. Nice-to-haves are “things to do if the team has extra time at the end and things to cut if they don’t.”

Done when: “Authorities can download the new export from the app.” Which item is a must-have?

Use the test: take it away. Without the button, authorities cannot download, so “done when” is false: must-have. Without the preview or the dark mode, “done when” is still true: nice-to-haves.

Week 5. The lead says: “The export must also work for a second authority, with its own format.” The “Out” list says: formats for other authorities. When is this a scope change, not scope creep?

Change is normal. It is a change, not creep, when it is decided in the open and the plan changes too: more time, or other work goes out. If the lead adds it and nothing else moves, it is still creep. Being the lead does not make the work fit.

A team meeting. Someone adds one more extra to the export. You are not the lead. Which question helps most?

With fixed time, new work must push something out. This question makes the trade visible, so the lead can decide. You need no lead powers to ask it.

Shape Up’s rule against scope creep. Type all four words: fixed …, variable …

Fixed time, variable scope: the date stays, the scope bends.

6. Your real-world task

At work, 10 minutes: a scope you can use

Pick one probat8 feature that is in work now, or comes next. Write five short parts:

Feature: its name, in a few words.
Done when: one result that you can check.
Must-haves: up to three.
Nice-to-haves: one or two.
Out: two things that someone would expect, but that are not part of it.

Send it to Claude. You get feedback on it, and Lesson 3 (who cares about this feature?) builds on it. This is the first part of your one-page plan.

Read this (15 minutes)

Ryan Singer, “Set Boundaries”, chapter 3 of the free web book Shape Up. Where “fixed time, variable scope” comes from, told with real examples from a small software company.

Want more? “Decide When to Stop” (Shape Up, ch. 14) on must-haves and cutting scope. And Oguz, 4.4 Project Scope Management, for what a full scope statement holds.

Questions?

Something unclear? Ask Claude, your project management teacher. No question is too small.