“Date, scope, and budget; choose any two!” I have heard that saying countless times—but it’s not precisely true.
It’s accurate to say that you can’t lock down all three variables on any interesting project/product-development effort and expect to succeed. Companies that attempt to lock down all three tend to have projects that are severely over constrained.
It’s not accurate, however, to state that you can “choose any two.” Unfortunately, that typically doesn’t work well. Instead, let me suggest a modified version of the old adage: “Date, scope, and budget; choose two, but don’t lock down date and scope together, and preferably, avoid locking down scope.
Here’s why. First, date and scope play a game of chicken with one other—they are coming right at each other and one of them had better give way. When we lock them both down so that neither can yield, we reduce our ability to maneuver in the presence of uncertainty. Then, when date and scope inevitably collide, our project will be left with a pile of technical debt—meaning we end up compromising quality.
Second, most of the time we should avoid locking down scope. There are, of course, some cases where scope is more important than date, but most of the time, we should let scope vary. Why? Because scope is the antifragile degree of freedom. The purpose of this blog is to explain this idea.
Antifragility
In another blog post I expounded on Nassim Taleb’s concept of antifragility and how it applies to agile software development. To summarize, things that are antifragile actually get better, or thrive, in the presence of disorder. When you have more to gain than to lose in the presence of uncertainty, you are antifragile; the reverse is fragile.
One example of antifragility is the body’s immune system. Up to a certain threshold (e.g., too high an initial dose might kill you) the body actually benefits by being exposed to a variety of pathogens. Being exposed to a small dose today makes it more likely the body will survive a much larger dose in the future.
Product development is inherently an uncertain (risky) endeavor. We don’t want to make decisions during product development that make us fragile. At a minimum we want to be robust or resilient to the uncertainty we face, and whenever possible, be antifragile and actually get better in the face of uncertainty.
It’s Scope, Not Requirements!
So now that we’ve reviewed the notion of antifragile, let’s talk about why I believe letting scope be variable is the antifragile degree of freedom. You’ll notice that I prefer the term “scope” to the more frequently used term of “requirements.” The problem with requirements is that the term implies that the items being described are actually “required!”
In manufacturing, requirements are actually required. If we are manufacturing a smart phone, we can’t just decide to eliminate the touch screens during this manufacturing run. Why? Because the screen is required; or we would produce a non-conforming product. We simply cannot ignore a requirement during manufacturing.
In product development, however, requirements are really a degree of freedom. On a product development effort if we start to run out of time and/or money what do we do? One common option is to drop requirements. So, how can an item be a “requirement” if it is not actually “required?” It is a suggestion, an idea, a degree of freedom for achieving our overall goal—it is scope.
Scope is a Multi-dimension Degree of Freedom
Scope is a good variable to put in play because it is a multi-dimensional degree of freedom. Scope has a binary dimension—a feature can either be in the product or not in the product. That is certainly an important degree of freedom, but we need not be so black and white. Scope also has shades of grey, or in our case, classes of metal. We could choose to include a gold-plated version of the feature, a silver-plated version, or a bronze-plated version.
I am not talking about reducing the inherent quality of the feature (i.e., the bronze-plated version doesn’t have greater technical debt than the gold-plated version). Instead, the gold-plated version of the feature has more bells and whistles or greater overall performance. Or, the bronze-plated version includes just the must-have aspects of the feature, whereas the silver-plated version includes some of the nice-to-have aspects of the feature and the gold-plated version has all of the nice-to-haves.
With so many degrees of freedom, allowing scope to vary makes us robust and at times antifragile to the uncertainty of product development because we have a lot of maneuverability that can protect us from change or make us better in the presence of change.
Fixed Scope Is a Fragile Approach
Let’s return to the caveat I added to my amended adage: “preferably, avoid locking down scope.” Locking down scope tends to make a project 
fragile. When we fix scope we presume to know the full set of requirements at the beginning of the project—the period of time when we have the worst possible knowledge we will ever have about the project. In the presence of such poor information, we generate an inventory of “requirements.” This represents a lot of work in process (WiP) that is waiting to be built. In addition, many companies will also try very early on to produce a rather complete project plan associated with developing those requirements (yet another form of inventory and more WiP).
Prematurely generating all that inventory when we have poor knowledge makes us very fragile to changing requirements—we might have to rework or throw out a lot of inventory that becomes invalid in the face of change. Since we have more to lose than to gain in presence of requirements’ uncertainty, we are fragile to that uncertainty, which leads to high change costs.
If we refuse to change scope when presented with better information, we end up creating sub-par products—we don’t benefit from adapting our products to better match the true needs of our target customers. This lack of adaptability is yet another form of fragility we experience when locking down scope.
Yes, there might be times when you need to lock down scope, but do so knowing you are relinquishing the antifragile degree of freedom!
Variable Date Can Be Fragile As Well
If we do choose to lock down scope, then—according to the new adage I put forth at the beginning of this article—we would let the date be 
flexible, because if we lock down date and scope at the same time we often have to compromise quality to meet both constraints. A variable date, however, adds additional fragility to our product development efforts. To be clear, by variable date I mean the project would take as much time as is necessary to complete the full set of fixed requirements.
Imagine, for example, that the product you are putting into the marketplace or the system you are releasing into production involves more than one team or group. One of the easiest ways to coordinate the work of multiple teams is to have all teams plan to rendezvous on a fixed, known future date. When dates are variable, the logistics associated with coordinating efforts increase dramatically, making planning in such environments very fragile. If one team moves (slips) a date, it has a domino affect across the plans of all other teams/departments, making the organization as a whole fragile to moving dates. Quite likely we have more to lose than to gain in the presence of dates moving.
We also have to consider the potential cost of delay of pushing back a delivery date. Cost of delay is the cost of time. When we push out a delivery date we need to consider:
- the extra cost of that time to pay for the work during that period
- the lost revenue of not having the product available
- or the lost opportunity to reduce internal costs by not deploying the system during the slippage period.
These delay costs can be quite disproportionate to the amount of date slippage. For example, in many business domains, product opportunities can decay exponentially—meaning if you miss the target date you lose almost all the value immediately. Imagine a tax software company in the US slipping its delivery until well into the tax season. It could easily lose most of its sales for that year due to that slippage.
Fix the Date, Not the Scope
Having a fixed date (with variable scope) is antifragile because this combination has more upside than downside (in the presence of uncertainty) for many products or projects. The good news is that often times the delivery date is definitively known or easily computable so fixing the date is often pretty straightforward and doesn’t involve a lot of guesswork!
The delivery date might easily be known because the product or system has to be available by a certain date—there could be a particular business event by which the result has to be available (e.g., the launch of the movie, update to be in compliance with a regulatory change, demo at an important conference, tax season, start of the school year, etc.).
Also, the date is often computable based on the economics of the project. For any project (or at least most projects) the sponsors should have in mind how much money they are willing to spend in order to achieve an acceptable result. I might want a solution for a price, but typically not for any price. If I know how much I want to spend to get the solution, I can calculate how many sprints I can do with the money I am willing to spend. Meaning I know my teams and what it cost to have each team perform a sprint, so if I know my budget and I know my per-sprint cost, I can quickly calculate how many sprints I can do with that money and therefore state with certainty the date I will deliver (or at least run out of money)!
Scope Is the Antifragile Degree of Freedom
Let me summarize thus far, fixing scope is a very fragile idea and in many cases varying dates is fragile as well. So a fixed-scope-variable-date 
project would seem to be a fragile approach to development. Locking down both scope and date typically only makes the problem worse (i.e., less degrees of freedom along which we can maneuver to meet our goals and a greater likelihood of compromising quality). Therefore, the preferred agile development approach is to fix the date and the budget and let the scope be variable.
This brings us back to my assertion that scope is the antifragile degree of freedom. Our willingness to vary scope as necessary makes us antifragile since feedback that we receive during product development can be used to learn and improve. In particular, that feedback helps us prune bad paths quickly and embrace emergent opportunities fast. Doing so will better ensure that we actually end up with a product that customers want, and not the product we thought they wanted on the first day of the project—the day we had the worst possible knowledge of what we should do.
Since we can actually end up with a better product in the presence of uncertainty we are antifragile to the uncertainty in the feedback we get regarding the requirements. Meaning, we actually have more to gain than to lose when requirements change—so varying scope makes us antifragile.
And, in those circumstances where we don’t actually get better from the uncertainty during project development, having variable scope better enables us to be resilient to changes. When we don’t lock down all of the scope at the beginning of the project we avoid prematurely creating a lot of requirements inventory that might have to change or be thrown out when things change. The product might not actually get better due to every change that happens during product development (if it did our project would be antifragile to all changes), but we are at least more resilient to those changes when they occur—which is much better than being fragile!
Conclusion
Date, scope, and budget—on agile projects we prefer to lock down date and budget and let scope be variable. We want to leverage scope as the antifragile degree of freedom to better ensure we can deliver real customer value by the target date with the available budget. What does your company do? Do you leverage scope to the extent that you can?