Minimum Viable Product and Minimum Viable Addition to a MVP

Invariably whenever I coach Product Managers and Product Owners, topic of Minimum Viable Product (MVP) comes up.  So, what is MVP? How you move forward once MVP proved itself viable?

Let’s try to explore the answers to these questions.  In my view there are at least two ways to visualize a product. The first view emphasizes the engineering view while second one is from business perspective. In engineering view a product can be considered a pyramid shaped structure in which bottom consists of functionality. As you move up connection with higher human needs keep on increasing.

The business view focuses on Value.

The Functional aspects of a MVP in engineering view get higher attention.

On the other side, in Business view, value takes precedence over any other thing.

To reconcile engineering and business view of MVP both stakeholders need to ask few questions and agree upon their answers:

a. Which functionality can I build into the MVP?
b. What is the minimum functionality to provide some value?
c. What version of my product can I build that captures most of the value?
d. How can I validate my value proposition?

Now you have a MVP and customer wants more of it. Now the question arises what to add into MVP so that it delivers the maximum value in present without compromising the near future technical and business viability.

Agile Team Capacity in SAFe

Calculating (or it should be estimating) capacity of an Agile Team in SAFe is a common challenge. To explore various techniques let’s build an Agile Team of following composition:

Product Owner count: 1

Scrum Master count: 1

Development Team members count: 7

Iteration duration: 2 weeks (10 working days)

Holidays during Iteration: 2 days

Planned vacations by the Development Team during an Iteration: 3 days

Technique 1: This technique is based on baselining of Story Point - one Story Point is equal to the one day of work by a person to develop and deliver a story end to end as well as explicitly call out that each member only works for 80 percent of the day in value delivery. 

Gross Capacity of an Agile Team = (Development Team members count)*(Iteration duration - Holidays during Iteration)*0.8 = 7*(10 - 2)*0.8 = 44.8 Story Points

Net Capacity of an Agile Team = Gross Capacity of an Agile Team – Planned vacations by the Development Team during an Iteration = 44.8 – 3 = 41.8 = 42 Story Points

Technique 2: This technique does baseline the Story Point - one Story Point is equal to the one day of work by a person to develop and deliver a story end to end and state that team does value addition only on 8 days out of 10 day Iteration. 

Net Capacity of the Agile Team = (Development Team members count *(Iteration duration – Holidays during Iteration - 2)) – (Planned vacations by the Development Team during an Iteration) = (7*(10—2- 2)  - 3 = 39 Story Points

As you might have noticed that second technique estimates the team capacity on higher side due to different treatment of planned vacations. 

Technique 3: This technique is a more general form of technique 2. In this technique it is assumed that out of 8 hrs. of working individuals only spend 6 hrs. on value addition activities.

Working hours each working day = 8 hrs.

Value addition hours each working day = 6 hrs.

Net Capacity of the Agile Team = (Iteration duration – Holidays during Iteration)*(( Value addition hours each working day)/( Working hours each working day))*( Development Team members count) – (Planned vacations by the Development Team during an Iteration) = (10-2)*(6/8)*7 – 3 = 39 Story Points

Technique 4: This technique is for mature team in a mature Agile environment. In this technique, relationship between Story Point and day/hours is eliminated. 

All Agile Teams in an ART develop a truly ordered scale to estimate stories. Each team of an ART contributes a representative story of size 1 to 8 on regular basis to the reference scale. Gradually this reference scale has multiple stories from each team of almost all sizes to represent Fibonacci series (1, 2, 3, 5, and 8). With time, teams start comparing the sizing of their respective stories from the reference scale instead of one day is equals to one story point. To keep reference scale current, generally any story older than one (or two) PI is dropped out.

Once a Reference Scale established and thriving, an Agile Team should estimate its capacity using velocity trend (provided team is stable).