I don’t think I coined this term, but my colleagues think I might have.
Imagine for a moment: you are working on a project with a hard deadline. You simply must hit your deadline. In that case, your greatest foe will be scope creep. In fact, anything that affects your timeline, is a serious threat and must be addressed. Regardless, in any project there are always unexpected issues that arise. Odds are, that some of them will affect your timeline.
If there is any chance that you might exceed your timeline, then you need to be ready to cut some features from your scope. Please let me be clear: you are not rejecting any features and you don’t want any features to get lost. It is more like: some of these features could easily be completed after you have met your deadline.
So the concept goes like this:
- Identify which requirements absolutely MUST be completed by the deadline.
- Any feature which could still be accepted after the deadline, goes into the timeline at the end.
- If your project runs over its projected timeline, then you can easily identify which features will be delayed.
- After you meet your core requirements, if there is time remaining, then you can include any features that will still fit into the remaining timeline. Or you can close your project early and start work on your “1.1” revision.
The next time you have a project with a firm timeline, try creating a “feature bucket” named “the edge of scope” and try to put as many features as possible, into that bucket. You and your team will sleep much better at night.