Isn't bottom-up project estimation anti-agile?

Discussions

News: Isn't bottom-up project estimation anti-agile?

  1. Isn't bottom-up project estimation anti-agile? (2 messages)

    DZone Agile has an article called "Bottom-Up Project Estimating." It describes bottom-up estimations as "the most time-consuming but ... also the most accurate."

    Here's the five steps used to show what BUE is:

    These five steps will send you on your way to successful bottom-up estimating:
    1. Identify All Project Required Tasks
    2. Estimate All Tasks Identified in Your WBS or Project Activity Definition
    3. Identify Task Dependencies
    4. Identify the Resources Required to Complete All Tasks
    5. Determine When Resources Should Complete These Tasks

    Step one... ouch. Isn't this the whole reason agile exists in the first place? Isn't "identification of all project required tasks" nearly impossible to do in the real world? Isn't this the same process that absolutely crushes waterfall development methodologies?

    Bottom-up estimation seems like it would be the anti-agile. Anyone managed to get it done where it was accurate? Is this article even worth taking seriously?

  2. We did use these bottom-up estimation in some of the project that had iterative development & QA cycles. I would put in somewhere between a pure waterfall and scrum model of project execution.

    Of course this bottom-up happened well into our development cycle once the design for the iteration was completed. Given our distributed team structure and many sub-modules it made sense to use the WBS to keep tight control, have many small milestones and multiple test cycles. The first iteration did have its problems but then we learnt the lessons and gradually improved in the subsequent ones.

    Given a similar execution environment, WBS still might make sense without being anti-agile

     

  3. You don't have to follow One Single Method to do things right. If you have many modules, you might have a high-level overview on most of the modules and estimate with high-level plans, but for the soon-to-be implemented modules you just do enlist the detailed features and tasks and estimate correctly (4-8 hours per item). This way it is not *that* painful, but remains as reliable as time you put into it.