Waterfall vs Agile and Project Estimates

[NeoRev]

I'm used to doing waterfall design and development. For my next project,
we're going use agile methodology. Well, it's not really agile. The only part
of agile they want us to do is to do iterative releases and have daily
stand-up meetings. I estimated the project to be 1,900 hours if we use
waterfall (which we won't, but I did it waterfall because that's what I'm use
to).

Now, I want to convert that waterfall estimate into an agile estimate. Is
there any rule of thumb or simple formula I can use?

I'm thinking that agile should take longer because of the iterative
releases, in that every release requires a new round of testing and
deployments.

Any thoughts?

A couple notes:
- We'll be using ASP.NET 3.5 and Visual Studio Team System
- This is not a full agile effort. Only iterative releases and daily stand
ups will be used. Business analysis and requirements were done waterfall
style.

 

[bruce barker]

normally for waterfall you do full requirements gathering, convert to project
specs, then esitimate the coding time for the specs. if you are not doing
formal requirements gathering and coding specifications, then you are not
doing waterfall, but rather ad-hoc coding, and waterfall scheduling (code ->
test-> release).

in agile, this estimate is done in iteration 0 (before project begins and is
usually a couple of weeks work). you create the story list ( features that
will be implemented). then you estimate the developement time (points) of
each story. then estimate the number points per iteration. this will give the
completion date. at the end of each iteration adjust the delivery date,
remove stories or increase velocity (number of stories completed per
iteration) by adding staff.

there are two main goals of agile:

1) release a fully tested working product at the end of every iteration. all
features added work 100%

2) work on the features in order of customer priority.

to be successfull at agile takes work and training:

1) iterative developement requires test first design and unit testing or
refactoring becomes impossible.

2) the developer(s) should have a bag of patterns in their pocket

3) writing unit tests generally require interface design and the factory
model.

4) paired programing helps with writing unit tests and passing the oral
knowledge used in an agile project.


I have used both waterfall and agile, and would never go back to waterfall.
I found agile projects deliver on time and less time (usually just a little
longer than the requirement gathering and project planning of waterfall)

in your example, a 1,900 hour (just shy of 1 man year) project in waterfall
should require 1000-2000 hours to produce the full specificaitions (Maybe a
100-500 hours for specifications for change orders and impact analysis. maybe
an additional 1,000 - 2,000 hours for the change order coding that occur
during the developement cycle.

in agile its still 1,900 hour project (coding is the same, just different
style) + the additional change orders. if you are coding properly in agile,
the change order have less impact. but there is no magic in agile, if change
order come faster then the coding (churn) you still will never get done, but
its more visible (new stories added faster than stories completed)

-- bruce (sqlwork.com)

 

[NeoRev]

Double it for the agile bloat overhead, then add an extra 50% for module

rewrites...

OK, I'm new enough to agile that I can't tell if you're serious or you're
joking.