Hack Your Agility: Building Minimum Viable Product

Are your requirements small enough to complete in a single iteration? Are you able to reduce the scope of a requirement when necessary? Does your development team support the practice of delivering minimum viable product (MVP)?

Traditionally, the business or the team comes up with an idea, defines requirements, fleshes it out, and then attempts to build it.  The requirements are often grand and define software that delivers some fantastic feature or complex functionality.  As a development organization, we spend our time trying to deliver this specific functionality without asking ourselves if we could deliver this functionality incrementally.  Instead of working for 4-6 weeks trying to deliver full functionality, and likely failing, can we deliver SOME of the functionality in 2 weeks? By looking at a requirements as a series of incremental stepping stones, we can more easily flesh out functionality and build out tooling that delivers actual value to the business because we can get feedback more quickly.

Consider a requirement where a mobile app needs to display a dynamically generated list of service centers on map.  This requirement may sound easy at first, and your team may believe it can deliver it in 2 weeks.   But this requirement does not define a minimal viable product.  What can your team deliver in 2 weeks that is potentially shippable?  What MVP would your business accept?  An MVP for this requirement might be a list of locations and addresses, with an understanding that you will link to a map in a future iteration.

The business may push back, stating that it doesn’t seem like much functionality, but we need to establish that we don’t even know if the customer will use this feature. It’s better to deliver something now than nothing later, and the business can decide partway through the long cycle that they are reprioritizing your work.  It’s better to spend 2 weeks on a feature that might be used, than 6 weeks on something that might not be!  And then we can gather feedback from our customer to prioritize what work do they want next!

As you accept a backlog item (requirement, user story, PBI) into an interaction, ask your team what the minimum viable product could be.  Then present it to the business.  Make sure they understand that you are trying to deliver value in a 2 week iteration and that you intend to deliver SOMETHING in a 2 week period so they can provide feedback.   Once you deliver something that works at the end of the 2 weeks (instead of 6), their feedback will help you to refine what you will be delivering in an upcoming iteration.  The business is likely uncomfortable with the idea of reducing the scope of a deliverable because they are used to getting everything at the end of a long development period.  Help them to understand that working with MVP each iteration allows them to better figure out exactly what they want and where they want to spend their resources by prioritizing what you will be working on!

(Original article appeared in June 10th 2015 edition of The Tempo)

About the Author:

Leave A Comment