What do you mean ‘we need more time’? Project schedule estimation in software
The tendency to estimate poorly - particularly to underestimate - is one of the key reasons to use a very tight, short-iteration agile process.<p>If I estimate something will take two days, and I&#x27;m off by 50%, it&#x27;ll take three days. If I estimate it&#x27;ll take two years, and I&#x27;m off by 50%, it&#x27;ll take three years. And because I can get a lot more practice at two day schedules than two year schedules, I&#x27;ll improve my accuracy over time, through steady practice.<p>This takes us back to the triangle of constraints that Kent Beck talked about in the first Extreme Programming book. There are three constraints on projects - schedule, scope, and resources. You can control <i>two</i> of them. Generally, resources are inflexible. So in practice, projects are either schedule-bound (we must hit this date) or scope-bound (we must have these features). A project that tries to do both, without a significant resource surplus, is probably doomed.<p>Since estimation improves over time with short iterations, it seems better to me to be scope-constrained than schedule-constrained. With steady progress, you can achieve the goals eventually. Good agile processes are much better at saying where you are and where you&#x27;re going than when you&#x27;ll get there.