Agile teams strive to achieve a vision given a rather fixed but reasonable budget (time and money). Even though this results in a flexible scope, expectations are usually much higher than what can be achieved. Investing into those features that really count is important.

When replacing a legacy system or in a competitive market where a set of features is demanded by customers, the feature scope is quite fix. As the available budget (time and money) is usually also quite small, the risk of failure becomes especially high. Stretching the budget a little is probably ok, but doing this repeatedly resulted too often in really big failures. Much better is to descope things. However, what to descope?

In both situations, the team needs to open the room for negotiating the scope. And to find that room for negotiating, here are three dimensions of scope:

• Breadth: The set of features a product offers.
• Depth: The level of sophistication achieved.
• Newness: The amount of innovation in terms of technology, market impact or organizational change enabled.

Breadth – free resources by reducing features

A team probably starts the negotiation with the breadth of features: Which features do customers and users really need? What will be the impact of not delivering a feature?

A good way to lead this discussion is to have a close look at users and customers and what they want to achieve and how: i.e. their journey or in a B2B context, the process your product supports. Where can the product add great value? Can we adapt the process and remove complex or useless steps? If a team did not look from this side so far, they will quickly spot features where value and costs don’t add up and do a significant descoping.

Looking at the journey will also bring up additional features offering great value to customers and users. Thus two more points of discussion can be led. First, features that contribute only little to the vision should be descoped. Second, a team does not need to realize all the identified potential at once. Usually, only a part of it is already ample for a worthwhile business case.

Here thus the three approaches to reduce the feature breadth:

• Vision: Descope features that do not contribute much to the vision.
• Value vs. cost: Descope features with little value for customers and users given the costs.
• Total value: Descope features to a degree, that a sufficiently big step forward can be made.

Depth – free resources by reducing complexity

The team can discuss the depth needed for a feature. What are the essential things so it can be used at all? Which things make it compliant with regulations and what to add to address security threats? Is it worthwhile to add comfort functions or to cover more special cases so users can use the feature much more smoothly? Is this feature even a significant part of the unique selling proposition and should therefore impress customers and influencers?

Teams develop features based on a foundation. The foundation usually needs a significant investment but offers relatively little value for customers. Once the foundation is built, some low hanging fruits offer good value for customers with little additional effort. If a team can reduce the depth of a feature and by that descope a significant part of the foundation, they free time to harvest a few low hanging fruits instead. Done well, the complexity of the feature is reduced and thus all the up-coming maintenance work will be reduced as well.

Newness – free resources by reducing iterations

Finally, the team can also discuss the amount of innovation to bring with a feature. Is the feature basically a copy of what was before? Is it a next step with major improvements and updated technology? Or does the feature even jump ahead and enables a major organizational change, opens the door to a different market or takes up an up-coming technology?

If a team rebuilds something they already did – with minor adjustments – they can often just specify, do and then test it. Thus they might just need one iteration and deliver a great solution. In contrast, radically innovative features imply significant changes for customers, users, the organization and the technology used. It will take several iterations to get it right. These iterations start already in discovery and continue well into life time of a product.

The bigger the leap, the more fails and iterations will be needed and the investment multiplies. A huge potential for cost savings.

Visualize the scope

Teams can reduce the scope significantly along the three dimensions. However, no price can be gained by delivering the bare essentials with no innovation, at least usually. It’s about finding the right focus: where does it pay off to be innovative or to deliver full depth? Where do you just copy the essential stuff and stick with it?

A feature chart can help a team visualize where to focus on: the team’s 3D scope. Side by side with a vision, this gives a great overview over what to achieve. For longer developments, where you create business scenario (see Business scenarios and 6 slicing patterns for product owners), the team can create such a map for each business scenario, showing how the feature set evolves over time.