Previously, I encouraged the use of critical chaining estimation when creating project network models as opposed to traditional project pathing.
The Agile Manifesto value to which that discussion pertains is:
Customer collaboration over contract negotiation
The ‘customer’ in this case is management and ‘contract negotiation’ is the product and capabilities required from an organizational standpoint. For instance, perhaps this product addresses the low-end of the market currently being serviced by an inferior. Executives want to service those clients to prevent the sort of entrant climb in capability that these unserved segments can fund.
At the level where individual contributors are pulling their respective implementation responsibilities, I agree estimates are superfluous. If the work can be delivered prior to the next delivery date, then it should be done. If it can’t then break the work down into properly scoped pieces or push it to the next cycle.
Realistically, Agile projects likely exist within a more traditional management structure. Some high-level of estimation will be required to win funding and support. Just as in all other projects, priorities may change. A feature that sold management on the idea may be abandoned due to external forces.
This becomes even more apparent when success depends on several sub-projects with different management styles. The existence of those buffers insulates the overall project from schedule changes at a much higher level.
It is in the context of these types of Agile project estimations that critical chaining becomes the more useful tool for project network models.