in software development things often don't go according to plan. Sometimes the fault lies with a third party vendor, sometimes you have to re-factor a design that no longer works and sometimes you get a bug that doesn't show up right away.
Whatever the case, you are way off estimate.
Developers will sometimes question if it even possible to estimate time on a development project.
You know what though. In reality few things of any complexity actually go according to plan.
So why plan at all?
Well for starters you need to commit to shipping a product. In business, saying we will build something someday doesn't cut it.
Others are depending on you and businesses need to meet deadlines too.
So we do the best we can and then adapt.
We have scope, budget and time. Time (schedule) is often not flexible. You don't want to blow the budget too often or you either won't make money or won't get invited back to do more work. Either outcome is not good for business.
So that leaves scope.
Scope is hard to estimate up front. Requirements change and better ways to build stuff comes up.
So you do rough estimating up front. Add in some buffer.
Then in each iteration you estimate the work for the sprint and commit to it. At the end of the sprint you know more and can estimate the next sprint a little better. The smaller the chunks the more accurate the estimates become. You win some and lose some.
If you are tackling the high risk stuff first, you reduce the likelihood of runaway estimates near the project end. As well, early on, don't focus on the bells and whistles. Be ready to go back to the drawing board on a bad code design. Too often developers just keep patching code rather than step back and redoing it.
Stuff happens and you adapt the plan. If you are working and communicating well with your customer they are not surprised.
When the time comes to ship you ship a working and tested product. The scope might be a little different, but it is usable.
And sometimes, despite everything, the S–t hits the fan at the last minute. Good teams can work through it.
Yes you can over plan up front (Waterfall). But no planning at all during the process is almost a guarantee of problems. Rough, refine, refine, ship. Agile applies to the code, design AND planning.
