Comments on: Underestimation is Underestimated

By: Moti Karmona | מוטי קרמונה

Moti Karmona | מוטי קרמונה — Fri, 30 Jul 2010 19:50:36 +0000

All is true…

By: Oren Ellenbogen

Oren Ellenbogen — Fri, 23 Jul 2010 14:01:11 +0000

Great post Moti, really well thought and well written. Indeed, underestimation causes drastic pains due to organization time versus personal time. If one is late, dependencies might be broken, shifting pressure (and late schedule) to other parts of the organization.

I feel that overestimation is also underestimated. Overestimation is why startup fails, why big companies moving too slow. Pressure is good, as long as it’s healthy and carefully watched. I would hate working for a company that does everything extremely well but takes 2 years to release simple functionality.

At the end of the day, it’s really matter of paying attention. Avoid wasting estimation time when not needed (far away roadmap), breaking features by end-to-end tasks instead of “UI”/”Business”/”Data Access”, pricing tasks by low granularity to allow confidence building and shifting tasks, considering organization time over personal time (add “design time”, “design review”, “code review”, “bug fixing buffer” etc).

We should focus on understanding where are we going and what we want to achieve, create a path to allow confidence.

Trying to avoid overestimation or underestimation is futile. It’s the stuff behind it that’s interesting, like you mentioned (mentoring)

By: Ronen Narkis

Ronen Narkis — Tue, 06 Jul 2010 22:32:47 +0000

This post made me think about what is common to the stock market and software delivery estimations, they both seem predictable at first but might turn into chaos due to the large number of factors that influence them.

Also like the stock market intuition and experience can make the difference.

By: Vivek Sagi

Vivek Sagi — Wed, 30 Jun 2010 13:00:16 +0000

Good post Moti and as expected from a engineering head…. :-)

Speaking from the other side.. of product management.. most times overestimation is the starting point for a discussion on scope because engineers (good ones atleast) tend to over design and over engineer even prototypes when some times speed to market is important.

By: Shlomi cohen

Shlomi cohen — Wed, 21 Apr 2010 14:19:08 +0000

let me clarify :-)
i’m not suggesting working in waterfall but ..
when you want to have quality requirement and design sessions to save some future investment then you might spend the whole sprint or even more on those.
when the requirements + design are not in the same sprint as the implementation = imho you are getting closer to “mini waterfall”

BTW – i wrote this message 3 times cause of errors and i only estimated 1 minute reply :-)

By: Moti Karmona | מוטי קרמונה

Moti Karmona | מוטי קרמונה — Wed, 21 Apr 2010 13:51:24 +0000

@Tzvika, thank you very much for the comparison! :)

@ Shlomi,

(1) I agree although this (e.g. learning) is something I prefer to manage/lead/control and not leave for chance.

(2) No way…! :) * requirement/design/testing/qa != waterfall*

Software development is iterative process (including design phase) and I don’t think anyone can really “do it right the first time” but design is a mandatory phase (no matter what methodology you use) to make sure “visible” design mistakes are not being made.

By: Shlomi cohen

Shlomi cohen — Wed, 21 Apr 2010 10:28:20 +0000

Really elaborating article moti,
i want to add another long term aspect, when people will have spare time as a result of “wrong” overestimation they will also learn more , will have the time to pick their heads and see what other teams are doing , learning more technologies etc, something they would never do if they are in pressure.
you mention about the requirement and design , to do it right the first time so we would not waist time on this later in project – do i hear the words mini-waterfall ? :-)

By: Tzvika

Tzvika — Mon, 19 Apr 2010 05:24:22 +0000

I like Joel’s approach: http://www.joelonsoftware.com/items/2007/10/26.html

Not surprisingly he aligns with you on not undercutting estimates… you dev managers are all the same :-)