Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..
- It should be the same, except that you do an internal release on specified dates to get a more realistic test of where the software really is (as opposed to doing a big bang release when the functionality is finally deemed sufficient and getting surprised by all sorts of things that do not really work like install scripts or even integration on some of the platforms).
The selection of the stories you do each iteration would still functionality-driven, so development should be identical.On 8/30/07, Simon Godfrey <Simon.Godfrey@...> wrote:I'd be very cautious of driving by dates rather than by functionality. The project I'm currently working on tried this initially and it failed miserably. We're now driving by functionality and things are moving forward at a much quicker rate. I think though, that largely this comes down to getting buy-in from those who're delivering the code and whether they feel they're having unrealistic targets imposed on them.As for estimation, could a pert-chart not be a good way to tie up the many streams of work and their dependencies?
> I have never EVER seen a single person mention real metrics whentalking about how great their agile projects are.
Besides the project velocity, % unit tests passing, reasonable work hours,
integration rate, collective code comprehension, and high code quality?
Agile projects generally force those details into your face.
"Agile" is essentially a system to detect when your project is agile.