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.
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]
