Precisa de ajuda para escolher o seu
treinamento ou tem alguma dúvida?

[Lean Inception] how to estimate the MVP and for the overall product effort?


Question: I love the lean inception article. But I have a very important question: my client wants to know when the MVP, and the whole product will be done. How to estimate?

Answer: This is the one million dollar question.
There’s always someone who wants to know about the schedule. And, typically, they want to know it for the MVP and for the overall product (a contradiction as we know the overall product will change as we start getting feedback — we work with MVP, and we’ll pivot!)

I did not add this to the Lean inception article because it brings too much confusion, even some contradiction. But I did add it to the Lean Inception book.


Feature Sequencer sample result

I use the Features Sequencer for this “estimation” (I don’t like this word at all; I am a proponent for the NoEstimates movement). On the book, I call this chapter: Calculating effort, time and cost.

On a Lean Inception, when required, I will guide the team on the following activities sequence to get some input for deciding upon a date.


To start with, I ask the team to detail two or three lines of features on the Feature Sequencer. Then, I ask for all tasks needed to fulfill the features. I will say something like: Assume a feature is delivered with the desired quality, in production, with all required tests, automation, scripts, cross-functional requirements, etc.

The team will write a bunch of tasks for each feature. Then I´ll use these detailed tasks to get the “estimation”.


I start by grouping them by relative sizing: small, medium and large. Then, I´ll ask the team how long it takes to deliver a few of these tasks. Usually they take similar duration (they have previously been grouped by relative sizing).


Then I ask the team to pick a duration for each task group. For example, small tasks answers are: 3 hours, 3 hours, 2 hours, 4 hours, 3 hours, 5 hours, 4 hours, 4 hours, 3 hours, 5 hours, 2 hours, 3 hours, 2 hours, 4 hours; I will ask if the team is comfortable considering a small task taking about 4 hours.


I do the same for each task group — small, medium, and large.
Then I sum the duration for all tasks, then divide by two (two lines on the feature sequencer). With this, I get a number. Let´s say 200 hours per dev for one line.

Now consider the team capacity: the number of devs working on these tasks; if the team is fully dedicated; vacations and holidays; sick leave and absence percentage. Then I´ll do the simple calculations, and show a date.

004-calculo-por-amostragem (2)

For example, the team has 4 devs, working on it only 80% of capacity (vacations, holidays and another stream of work, such as bug fixes on another product)

  • 200 hours for 1 dev => 50 hours for 4 devs
  • 50 hours at 100% capacity => 62.5 hours at 80% capacity (50 hours * 100%/80%)
  • Each line on the feature sequencer takes 62.5 hours for our team

I know this gives a bad feeling for some developers. It gives a number that we can convert to a date (don’t forget to add iteration 0 to it, with the work that needs to be done before starting on the functional work).

Typically, people at the client love this activity.  They get a date for the MVP, and they are able to extrapolate the calculation for the whole product (all lines on the Features Sequencer).

But it is not bad for the developers. Not at all. They have something to help them out: the MVP with its high level features. The point is, the Lean Inception result, as depicted on the Features Sequencer, depicts the MVP features. But it does not detail how they will be created (the tasks were used only for sampling). Therefore the team can (and should) be creative and responsible for delivering it, respecting any given date. Rethinking how to deliver the functionalities with simpler tasks, which require less work, to achieve the minimum viable product.


[content_block id=2985 slug=baixe-o-tothepoint]



Paulo Caroli

Paulo Caroli is the author of the best-selling book “Lean Inception: How to Align People and Build the Right Product” (the first on a series of books on business agility). He's also the creator of FunRetrospectives.com , a site and book about retrospectives, futurospectives and team building activities. Caroli writes on this blog frequently. Receive the next post in your email. Sign up here.
Lean Inception: Learn How to Align People and Build the Right Product

Lean Inception: Learn How to Align People and Build the Right Product

Lean Inception is a crucial agile methodology for aligning teams on effective product creation. Introduced by Paulo Caroli, it combines Design Thinking and Lean StartUp techniques to define strategies and Minimum Viable Product (MVP) scope. It is valuable for large projects, startups, and business innovations. Not suitable for discovery activities, prototyping decisions, or cross-team alignment. Active participants, stakeholders, and skilled facilitators are essential for the success of this collaborative process. Lean Inception is fundamental for guiding teams toward meaningful and efficient product outcomes.

read more
MVP philosophy and the Justified True Belief

MVP philosophy and the Justified True Belief

Lately I have been listening and reading about philosophy and I came across a theory that got me thinking about hypothesis driven development, Minimum Viable Product (MVP) and validation. It is accredited to Plato from around 369 BC with the name of Justified True...

read more

Pin It on Pinterest