Deadlines and estimation errors

After looking at the diagram in the MVP explanation, I personally feel that it applies well to cases where there are deadlines that cannot be moved, such as presentations and results debriefings.

If you're developing with the intention of being in the rightest shape at the deadline, and the time it takes to develop takes a little more than planned.

• So-so on the bottom.
• The top is terrible. Since the cost of implementing a task cannot be accurately estimated in advance, it is necessary to anticipate fluctuations and put the task into a "presentation-ready" form early. #Estimating #Uncertainty

It makes sense that the lower flow has more steps in this diagram. Considering the total number of man-hours, the lower end is less efficient because of the time spent making the extras. Still, the inefficient lower process is better than the seemingly efficient upper development process, and this paradox is an interesting point.

For example, let's say that one step is estimated to take 10 days. Let's say the presentation is in 40 days.

• The plan above is "4 steps of 10 days per step will result in completion and a score of 100. Until then, you score zero."
• The plan below is "5 steps of 10 days per step will get you to 100 points. Until then, you go up by 20 points." The lower plan requires 20% more man-hours. In other words, development is inefficient.

If the estimate is accurate.

• The plan above can be a perfect 100-point demonstration at the results briefing.
• The plan below will not be ready in time and will be an 80-point demo.

In reality, however, estimates are not accurate. Suppose the estimate is off by plus or minus one day per step.

• The plan above has a 50% chance of not being completed in time and scoring 0, so the average of 0 and 100 scores is 50.
• The plan below has a 50% chance that step 4 will not be completed in time, with an average of 60 and 80 points for a score of 70. Despite the lower plan being more inefficient, the lower plan was on average rated higher in the presentation.

Independently of this "deadline and estimation error," there is another way of thinking that "'The customer must want something like this' is a hypothesis, so we need to create a 'form that can be shown to the customer' (MVP) as quickly as possible, actually show it to the customer, and verify the existence of customer needs," which is the so-called "Lean" philosophy. That is the so-called Lean philosophy.

• deadline and Estimation error

#Mindset

This page is auto-translated from /nishio/締め切りと見積もり誤差 using DeepL. If you looks something interesting but the auto-translated English is not good enough to understand it, feel free to let me know at @nishio_en. I'm very happy to spread my thought to non-Japanese readers.