{"id":4336,"date":"2017-07-26T10:18:59","date_gmt":"2017-07-26T10:18:59","guid":{"rendered":"https:\/\/caroli.org\/en\/?p=4336"},"modified":"2021-11-03T08:16:53","modified_gmt":"2021-11-03T11:16:53","slug":"tothepoint-estimate-mvp-overall-product-effort","status":"publish","type":"post","link":"https:\/\/caroli.org\/en\/tothepoint-estimate-mvp-overall-product-effort\/","title":{"rendered":"[Lean Inception] how to estimate the MVP and for the overall product effort?"},"content":{"rendered":"

Question<\/strong>: I love the lean inception article<\/a>. 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?<\/p>\n

Answer<\/strong>: This is the one million dollar question.
\nThere’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!)<\/p>\n

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.<\/a><\/p>\n

\"feature-sequencer-sample-lt\"

Feature Sequencer sample result<\/p><\/div>\n

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

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.<\/p>\n

\"sampling\"<\/p>\n

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.<\/em><\/p>\n

The team will write a bunch of tasks for each feature. Then I\u00b4ll use these detailed tasks to get the \u201cestimation\u201d.<\/p>\n

\"features-tasks\"<\/p>\n

I start by grouping them by relative sizing: small, medium and large. Then, I\u00b4ll 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).<\/p>\n

\"features-tasks-sizes\"<\/p>\n

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.<\/p>\n

\"004-calculo-por-amostragem\"<\/p>\n

I do the same for each task group — small, medium, and large.
\nThen I sum the duration for all tasks, then divide by two (two lines on the feature sequencer). With this, I get a number. Let\u00b4s say 200 hours per dev for one line.<\/p>\n

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\u00b4ll do the simple calculations, and show a date.<\/p>\n

\"004-calculo-por-amostragem<\/p>\n

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)<\/p>\n