Last few months I have been fortunate to be leading complex enterprise initiatives using the agile framework that have in the past been delivered successfully using the traditional waterfall model .Thankfully due to a load of awareness created by the Agile community in recent times, convincing our sponsors and stakeholders to take the agile route was the easiest.The most challenging area however was planning the sprints and the overall release planning.

No matter how much sense it made to the IT team on how we structured our sprints based on technical features or capabilities we still had the challenge of getting our key stakeholders i.e the business testers to participate in our sprints. So back we went to the whiteboard to figure out the missing link and then there it was – the sprints either independently or as whole for the release were missing a viable product that would add business value. Yes we were bringing in tons of data and writing really complex ETLs and interfaces to extract and manipulate the data, but the actual business functionality was getting released in future releases and further planned out sprints.In an ideal world we still would have been able to succeed with our current planned approach, however in the real world we could sense the risk of our stakeholder’s patience running out. So we replanted our sprints and releases focusing the minimum viable product (MVP).

What is a MVP

A MVP is a subset of the scope or the feature list that has a tangible business value that can be used by the end users, client or customers. The way you define and identify a MVP will vary with the type project or product. However what is constant is that these are a minimum list of features that justify the investment of time and resources for the sprints early on. A minimum viable product is different from a minimum desirable product. A minimum desirable product goes beyond viability to include more scope and features from the requirement or scope document. Ideally you should plan a agile release or sprints with a MVP progressively moving to the MDP state in the next iterations that would deliver maximum business benefit and customer delight. Did I hear someone mention scope creep? , I will pass it for now for a different discussion.

How do you identify the MVP

Don’t start building or executing your sprints until you have identified your MVP. The below 5 step process to identify and define a MVP worked for us

1. Identify stakeholders who are responsible for defining the MVP. Based on your project, it can be either the product owner or the business sponsor along with any other key team members. What is important is that this individuals or the group is identified so they can make decisions around the MVP.
2. Use the scope document or the product backlog as the starting guide and run this with the sprint teams to plan out the MVP for your sprints or releases. An MVP technically should be a subset of this scope document or the product backlog. if this is not the case then you need to go back and get your product backlog and /or your scope document in order.
3. Limit the number of interdependent features that you include in your MVP. Focus on the viable, but keep the minimum in mind. Having too many interdependent feature will limit your ability to do so.
4. Prototype your MVP to get stakeholder feedback before your start your actual development, build and execution. In certain cases, having multiple MVP prototypes will help stakeholder choose the most suitable one.
5. Align your MVP with the strategic business goal that the initiated project or product supports. You need to be able to build upon this MVP as you move forward with your sprints and releases. Yes, an MVP may be a moving target, but you should not have to redefine your MVP from the scratch.

We are still a long way to go with respect to perfecting this process, however with a couple successful releases behind us, we feel confident that our approach works and excited as we move forward with it. What we learned in the process was that the concept of MVP assumed greater significance as we roll out projects and initiatives using an Agile framework.