As an engineering manager, one of your biggest challenges is defining the scope of a software project. You need to balance speed, cost, and quality—the classic Iron Triangle of software development. You can have things good, fast, and cheap, but not all three at once. When defining what "good" means, you enter a negotiation between the engineering team and the product manager, deciding what is truly necessary for a successful release.
A powerful tool for making these tradeoffs explicit is the Line of Embarrassment—a literal line in your backlog that separates what must be done from what would be nice to have.
Think of the tasks in your backlog as sitting in one of two buckets:
Using this approach, you focus your prioritization effort on the tasks above the line. Those below the line exist, but they do not consume the same level of attention in sprint planning.
When you build a plan for delivering a software feature, your backlog quickly fills with tasks—some essential, some aspirational. The Line of Embarrassment is a tool for efficiently parsing your backlog so you can clearly see how much real work remains. Here’s how you can use it effectively:
Before you determine what sits above or below the line, align with your team and product partners on what "good" means. What must be true for the feature to be usable, stable, and supportable? Document these as explicit release criteria.
Prioritize the work that must happen. You can refine ordering above the line to ensure the most critical or risky tasks are handled first, but you don’t need to fine-tune the ranking of below-the-line tasks.
It’s not just about writing code. If your team ships a feature but can't support it, you will be embarrassed. If Sales and Customer Success don’t understand it, that’s also a problem. Any required documentation, monitoring, alerting, or internal enablement must live above the line.
If you use story points or other estimation techniques, summing up the effort required for all above-the-line work gives you an actual number to compare against your target ship date. If the work is too large for the given timeline, you have two choices:
This makes the conversation around tradeoffs clear, dispassionate, and objective.
As the project evolves, some below-the-line work may need to move up, and some above-the-line work may prove unnecessary. The Line of Embarrassment isn't static—it should be revisited regularly to reflect reality.
The Line of Embarrassment is an effective mental model because it forces discipline in prioritization and makes scope decisions explicit. It provides a clean, communicable framework for discussing tradeoffs with stakeholders and ensures that teams stay focused on what truly matters.
By integrating this into your backlog management, you create a structured yet flexible way to navigate the inherent uncertainty of software development. Instead of endless debates about whether a feature is "done enough," you have a clear, shared standard—ensuring that when you ship, you can do so with confidence.
So next time you're deep in delivery planning, draw the Line of Embarrassment—and use it to ship smarter.