Introduction

Developers understand in theory what a minimum viable product (MVP) is. Do they understand what that means in practice? One of the keys is build out the behaviour, not the functionality. The business wants a lean solution that has the value-add behaviour.

The original idea of the project management triangle is quality is a product of time, money, and scope. Agile challenges the definition of scope. Scope isn’t defined once at the start of the one-year project. Instead it’s an iterative process over the entirety of the project. There is a popular adage in software development. We started off thinking we needed a bridge, but instead built a ferry.

The minimum viable product definition used in this article is the following. The smallest behaviour necessary to solve the defined customer need. This definition throws out a few common pitfalls.

For one, the “Anemic Domain Model” popularized by Domain Driven Design is now avoided. Developers no longer construct a system that retrieves and stores data. Instead, they ask what is important to the users with this data. Does the user want to calculate revenue, costs, or track some other obvious behaviour?

The “smallest behaviour necessary” wording is important. There are no “bells and whistles” or “side quests” in an MVP. Instead, we build out only critical features. These feature(s) are the reason the customer wants to use the application. We are generally talking about a single feature, two at the most. Too often teams hope that more features mean more money, and often this is the opposite of true.

What does the use of “agile” in “agile MVP” mean? The key to the development is short iterations of the scope definition. Feedback is central to definition of the solution. Short feedback cycles are the cornerstone of agile. These cycles mitigate risk from large project scopes. We are avoiding building a large solution that does not solve a customer need.

The Limitations of Traditional Scope Management

Construction projects use conventional scope management. A team decides to build a bridge, scopes out a design, and then builds it to the specification. The final design matches the initial design as exactly as possible. The limitation of this is any unforeseen circumstances are not budgeted. Adjustments to the design based on customer needs, or learning are not possible. A bridge has a stagnant customer need, provide passage over some impediment (eg: water). Society has built bridges for hundreds of years. There are not a lot of innovations in the discovery of building a bridge.

Agile scope management requires clear, actionable goals within each sprint. Create stories that fit roughly within 1-2 sprints, and then set out to achieve them. Avoid making these stories either too large or too small. Granular stories can result in micromanagement and over-fitting solutions to problems. Large stories do not provide enough insight into the day-to-day operations. Regular demos of new feature developments provide valuable feedback to developers. Inject as many feedback mechanisms as possible the development of features. Define sprint objectives, break down user stories, and hold sprint planning sessions.

It’s important to continuously groom the backlog. Make regular updates to product ideas, based on user feedback. Incorporate lessons learned from the development of the software in the backlog grooming. Apply a value-based prioritization schedule (Must have, should have, could have, won’t have). Balance the short-term wins with long-term vision.

Keep stakeholders informed. Stand-ups, retrospectives, and other feedback loops contribute to this feedback. One on one’s with managers help distribute the knowledge throughout the organization. Understand the important feedback in each context. The goal of these feedback loops is to better inform the scope of the product and its features. Develop adaptive roadmaps to accommodate changes in your product.

Conclusion

A fundamental difference in agile development versus old-school waterfall is the project scope. Understanding how scope fits into agile development is a cornerstone of the philosophy. Use the ceremonies surrounding agile to guide the product direction.