What’s “in Scope?”
So let it be written, so let it be done… I’m creeping [scope]
1. Introduction
Everyone has heard of scope. And everyone knows it creeps. But what is scope in the context of software development? Why is scope so hard to get right? Why do software projects constantly fail to meet time or budget constraints, and why are customers always disappointed after buying in to the hype?
It all starts with the MVP.
2. The MVP
In software development, the MVP is the Minimum Viable Product . Let’s unpack that. First, it must be a product. According to Webster, a product is something that is made to be sold or used. In software, it’s a program or application that can be used to obtain or create business or personal value.
Minimum should be self-explanatory but is often overlooked. It is the smallest application that delivers one quanta of value to a user. Consider a primitive calculator. It needs to receive inputs, perform an operation, and display the result. It adds value by rapidly and accurately performing calculations. Seems easy – but does it need to add, subtract, multiply, or divide? Just one? All four? Depends on the needs of the product’s customers. And that leads me to viability.
Viability means that it satisfies the customer’s expectation of a product that they will use to unlock value. It is probably the single most important quality of your product. You can make a calculator that just does addition, but it won’t find many customers outside of first and second grade children. That may not be a viable product. To access the broader market, you will need to be able to add, subtract, divide, and multiply. And perhaps a few more features on top of that.
Therefore, we can think of the MVP as the minimum set of features needed to deliver value to a target market. But there is one more issue that comes into play: competition. For most products there is an existing solution in the marketplace that needs to be displaced (even if it’s inertia). So typically, product designers will include some degree of feature differentiation when thinking of whether the MVP is in fact viable.
How do you know if a feature belongs in the MVP? Ask yourself these questions: Is it on a critical path for delivering value to the customer? Does it significantly increase product differentiation? Does it significantly impact the value proposition we offer our customers? If the answer to all of these is “no,” it does not belong in the MVP. If you get a “yes,” you should really try to understand the reason driving the answer before you commit to adding the feature to the MVP.
3. Scope Change vs Scope Creep, and when to Cut Scope
I think that pretty much everyone would agree that it would be foolish to continue developing software when there is a clear understanding that it is no longer viable. And yet, this happens on countless software projects. Entire industries of software development consultants, best practices, and management principles (I’m looking at you, SCRUM and AGILE) have been developed to avoid this pitfall. But their advice usually boils down to the following: Constantly challenge your assumptions and hypothesis of what a viable product is and test those assumptions with prospective customers in your target market.
If you find that your assumptions are flawed or your MVP doesn’t resonate with your target customer base, you need to change scope. This is good news! You’ve gotten early feedback and avoided some future problems without dumping good money after bad. If you figure out that no one buys calculators anymore (except for specialized, highly differentiated ones) because we use apps on our phones – better off figuring that out before you’ve committed capital to manufacturing! It can be disappointing to change scope in the middle of a project, but ultimately it will lead to more positive results.
Scope creep, on the other hand, is the cancer that strangles the life of projects through delays and cost overruns. It manifests itself in the multitude of tiny, incremental feature requests, or edge cases to support. Effectively, there are an infinite number of features that can be added to any application.
On our calculator, maybe the user wants to resize the font on the output display. Or maybe they want a physical “double button” – pressing that button multiplies the result by 2 (don’t laugh, most old calculators and even the calculator app on my phone still has a percent button). These features could certainly add value to a subset of users. But is it real, differentiated value? Or is it just incremental?
One way to test for scope creep is to put a cost to any change. In construction, general contractors are great at this. Any change to the agreed scope has an up-front penalty in addition to the actual cost of change. That’s not always practical when we’re building software, but we can ask customers hard questions to better understand the business need behind the feature request.
Here are a couple examples of questions to ask customers or end-users that you might add to your bag of tricks:
- · If we add this feature, is it OK to delay the project Y months?
- · Will you cover my costs for the work to add this feature?
- · Are you willing to pay $X for an upgraded version of our application that has this feature?
Usually when faced with the realities of delayed time to market or increased costs, customers can begin to have more realistic conversations and expectations about what belong. Another way to handle scope creep is to prioritize all features into two phases – phase I and phase II. Phase I is definitely going to happen (that’s the MVP!). Phase II will happen only if customers are happy with Phase I. Ultimately, we only get to work on the nice-to-have features if the have-to-have features are working!
Unfortunately, life finds a way to challenge even the most well thought out project plans, and we must cut scope. This may happen due to resource constraints, external/market deadlines & timing, or technical constraints that limit the feasibility of planned features.
Facing these constraints usually forces me to go back and reevaluate our MVP definition. Is this feature really creating value and differentiation? Is there another way to create that customer value that is more cost/resource/time effective? Is the value of having a smaller-scoped project on the market larger than having a more developed MVP (eg, first mover advantage)? Once you’ve completed this exercise, you may ultimately be forced to allocate more resources (time, budget).
What do you think? Have you experienced any of these issues? Let me know below!