Scope-Driven Development - What Could Possibly Go Wrong?

Have you communicated a clear decision about how to order Quality, Time, and Scope in your team’s product or service development work? If not, you're likely not getting the best results.

Without clear guidance on the relative priority of Quality, Time, and Scope, organizations tend to put Scope first, offering a wish list of capabilities as MVP

Scope is the capabilities or features of the offering. This is usually captured in a requirements specification, a set of agile epics or stories, or a conception of Minimum Viable Product (MVP).

Quality can mean freedom from defects or fitness for use. Let's take it to mean both things. The first definition is about meeting specifications, and the second is about marketability and usability.?

Time can be expressed as an estimated release date, an imposed deadline or time-box, or a cadence of releases with fixed cycle time.

Without clear guidance on the relative priority of Quality, Time, and Scope, organizations tend to put Scope first, offering a wish list of capabilities as MVP. Once a scope-first program is underway and starts missing estimates (see column B), management imposes deadlines based on financial constraints. To make the deadline while checking off as much scope as possible, teams push defects downstream and into the field.

You are left with software that pleases nobody. Unreliable, late, and incomplete. Poor quality damages your reputation and credibility, and is much more expensive to fix (100x is a common estimate) than it is to prevent.

Poor quality damages your reputation and credibility, and is much more expensive to fix than it is to prevent.

Why not (as in column C) put quality second and let the delivery date float?

Time uncertainty is very hard for management and customers to understand. Leaders expect their teams to show progress often so they can identify troubled projects. Stakeholders expect to see progress points and may be making sales commitments on product delivery. Customers need to plan their own work and may have financial deadlines imposed on their ability to buy. The real world is not very accepting of time uncertainty.?

Putting Scope last is cringe-inducing for most product managers

Putting scope last (column A) is cringe-inducing for most product managers, but it has some real advantages. First, without field evidence in the form of customer conversations and sales, nobody really knows what capabilities are important. MVP and other scope-driven ways of specifying products are often opinions of well-informed but fallible people. If you deliver high quality software on a regular cadence (i.e. on a constant cycle time like every quarter) but miss some scope, you have an immediate opportunity to check whether the missed scope matters and a chance to get it right in the next release.

MVP and other scope-driven ways of specifying products are often opinions of well-informed but fallible people

If you are late with a delivery or have poor quality, you will annoy essentially all your stakeholders. If you miss some scope, you will annoy a few, but have a chance to atone in the next release. Consistently delivering high quality software on a cadence makes it simpler to develop a continuous improvement culture and builds credibility with customers and internal stakeholders. This is especially true if you tell them that they can count on the date and the quality even if the scope sometimes falls short. Product managers will adjust to the idea that they have to choose the most important capabilities that will fit into the release, knowing that releases occur frequently enough that course can be corrected and shortfalls can be compensated. Senior management can see and measure progress because they can market test working software every release, and releases happen reasonably frequently.?

If you are late with a delivery or have poor quality, you will annoy essentially all of your stakeholders

Our understanding of requirements is imperfect, so our estimation is also imperfect. All we can really expect to do is improve with experience. A repeatable cycle of Quality, Cadence, Scope is a very effective way to drive this learning loop.

So choose column A and communicate clearly to your team and stakeholders. Make scope the dependent variable and hold to high standards on quality and cadence. With those constraints the team can get creative about working so that scope can be ejected from a release when it must be, and so that this is rare.

• If you found this useful, follow me for more insights!