1–10 of 39 posts
Software houses want to project themselves as intelligent collection of beings, but why can't they see the truth that there?
If we're talking about effort, timelines, etc, then it does work. You are right that it generally doesn't work on the surface. However, even if the estimates are wrong, the benefit is that the artificial dates and such provide a mental push. In some cases dates are important, to meet a business deadline, beat a competitor, etc. Breaking that up and pushing it down to smaller stories means more feedback which provides more of that 11th hour push more often.
And then of course things like costs and staffing are crucial to any business.
I once had a huge discussion with the Architect because I said something would take an year to finish and the Architect was claiming it would take 2 months. He would not understand that the remaining 10% of the task would take 90% of the time (yes, it was partially complete and I had been following its development from the start, although never involved in it directly). In the end they went with his estimation but it took 2 years to finish the thing.
Still, I think estimation is important, once you actually listen to the estimations and understand it really depends on who is doing it.
Also, the process of estimation very often reveals difficulties or unknowns that nobody was even thinking about previously. That's the whole purpose of estimation happening via unanimous planning poker -- the discussion as to whether a feature is a 3 or a 10 is incredibly valuable in getting on the same page as to what the feature even is.
Steve Mconnell dispelled many of the misconceptions around project planning and estimation around twenty years ago. Worth a read.
While it may be true, saying "it'll be done when it's done" isn't useful. All tasks involve some aspect of uncertainty. Coming up with an at least half-way decent estimate requires a team to break down the problems they're facing into smaller chunks that can be estimated. This is a useful exercise when it comes to prioritizing projects, budgeting, and go/no-go decisions.
There are many ways in which estimation as an exercise can be corrupted. Some people, particularly those who haven't written software themselves, treat all estimates as accurate. In their mind, that "I guess 3 months" estimate a developer gave quickly turns into "I can 100% deliver this to you fully tested, with all of the additions you added along the way in 3 months". This over-indexing often leads to the situation where a developer is disciplined for not meeting expectations, even though they tried their hardest to do so. Some people don't like the estimates they are presented with, so they seek out a lower estimate. They are then shocked when the project takes longer.
Because you can't go to money people with "it'll take as long as it takes". It may be true, but that doesn't fit in Microsoft Project, and as long as there is another reputable group out there providing estimates, even junk ones, people will expect them.
1 day
1 week
1 month
3 months
6 months
1 year
3 years
if you had a random project, do you think you wouldn't be able to pick the most likely estimate and be within one level above or below? so "i have no idea, it'll take as long as it takes" is not really true.