The #NoEstimates Debate

[Ronan Healy]

`This is a debate that I am coming to quite late.

Can anyone explain the nuances to me?
From what I understand, the main debate seems to be about should projects have an estimate for time, cost, difficultly etc for a project or not?

But some have stressed that the debate has little to do with estimates.

Does this seem right. Why is there so much discussion about this aspect of a project?

And how does testing fit into this debate?

[Kasper]

The discussion is there because software development is still not very good at estimating.
Projects are often late, over budget and short on features.
In stead of fixing the issues that make software projects so hard to predict the simple solution is not giving any estimates at all.
Of course this can only be done when you have no other software depending on your code. Or business. And you don’t depend on anyone else.
So basically: if you are working in a garage to make the next Spotify or some app: go for it (and hope the financiers put up with you).
In the world of business applications: not so much..

[Melvin]

I think estimates will still remain on use for projects that integrates different application or have different dependencies, is part of the basic planning of resources. Although is true that is hard to accomplish the estimates and several times during development cycle we realize that estimate won’t be achieved, at least it gave us an idea at the beginning of the cycle of what we will be facing.

[Ronan Healy]

Melvin wrote:

I think estimates will still remain on use for projects that integrates different application or have different dependencies, is part of the basic planning of resources. Although is true that is hard to accomplish the estimates and several times during development cycle we realize that estimate won’t be achieved, at least it gave us an idea at the beginning of the cycle of what we will be facing.

I agree with you @msalazar18, it does make sense to have a timeline when working on a project so that you know how long you have/it will take.

@kasper I’m still not tool sure. What are the advantages to a business having no estimates for projects? Does it give them more room to work on the various aspects of a project and really tackle each area?

[Kate]

The way I see it estimates are a tool. The more granular the thing you’re estimating is, the more accurate it will be, but if you roll all the task estimates up to the project level, the accuracy of the estimates drop. (If a typical task estimate is about 95% accurate, and there are 64 tasks in the project, the project estimate will be about 3% accurate… Of course, most projects are much bigger than that).

That said, for a reasonably well-understood project in an application or domain the team is familiar with, project estimates can be quite accurate. When management insists that the estimate is too high, or new features are shoehorned in without adjusting scope or time allocations, there will be problems.

I can’t see businesses ever accepting no estimates for projects: they use those estimates for budgeting, and no healthy business is going to ignore something with such an impact to its bottom line.

[Swasati]

IMHO : As the whole software development gets funded from Business, the existence of IT industry to enhance business and generate Profit. It is important to have an estimate to set expectation, provide a plan and vision to Business.

Usually estimate process fails due to ambiguity in most difficult phase which is “Requirement phase”.
The whole world going gaga about “Agile”, but in practice Agile gets used as “iterative Prototype making” or “Trail and Error” process. This methods are useful for Research and Developement and there estimate could be relaxed. But in known domains, the “Requirement phase”, needs a “Bird eye view” but often “Worm’s-eye view” gets presented with hope that as we progress in Project, the Vision will evolve—-NO NO NO.

Vision needs to be concrete, if not, prolong “Requirement Phase”, use all tools for survey and feeds, get the best Business Analyst with Domain knowledge. Please bring back the old fashion “Entity-Relationship” diagram, the “Data-Flow” diagram.

[Author]

Posts