File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Entering Feature Freeze Phase Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Entering Feature Freeze Phase" Watch "Entering Feature Freeze Phase" New topic
Author

Entering Feature Freeze Phase

Ted Young
Greenhorn

Joined: Aug 10, 2004
Posts: 6
We've been chugging along with two week iterations for the past 6 months or so and it's generally been working well. We're about to enter the "feature freeze" phase, where we won't be adding any (significant) new features and mainly cleaning up the existing features, fixing bugs, and writing more customer and programmer tests.

I've been struggling with trying to figure out how we're going to come up with stories and then estimate them, when many of them are going to be bug fixes that need troubleshooting before we know what to fix. During our feature development phase, those bug fixes have just been part of our process, i.e., we fix them as we find them, so they're "baked in" to our velocity. But now we're at the point where such effort can't be baked in to anything.

How have other people approached this?

;ted

Software Developer and Agile Coach
Guidewire Software, San Mateo, CA
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Accounting for bugs and rework is a neat tale. It avoids the "baked in" overhead in velocity, and makes bug fixing very visible instead.

I always chafe at "go pure XP" suggestions that don't recognize the realities of working in my particular cube maze, but an "ideal" idea might be "don't have a feature freeze" and replace the big test & fix at the end with more effective testing in every iteration.

Any chance you can start racking up points on release n+1?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Originally posted by Ted Young:
We've been chugging along with two week iterations for the past 6 months or so and it's generally been working well. We're about to enter the "feature freeze" phase, where we won't be adding any (significant) new features and mainly cleaning up the existing features, fixing bugs, and writing more customer and programmer tests.


A major aspect of Agile development is supposed to be that the software is always ready to be delivered. At any point, it should contain the most valuable stories (as defined by the customer), so that if development stops right then, the customer gets the most valuable product given the time spent.

With all that in mind, I need to ask how valuable the work you are considering is to the customer?

If the presence or absence of a particular "bug", or the unreliability of a feature is significant to the customer, then correcting the problem can be considered and tracked as any other "feature".

If the presence or absence of a particular "bug", or the unreliability of a feature is not significant to the customer, then there is an argument that you should not be working on it!

I've been struggling with trying to figure out how we're going to come up with stories and then estimate them, when many of them are going to be bug fixes that need troubleshooting before we know what to fix.

I've usually found that stories for bugs are easier to come up with than stories for new features. You should be able to use almost any bug reporting template along the lines of "when I do X then Y happens, but Z should happen instead". Code this as an automated acceptance test, then TDD to a solution.

As for extimation, presumably the process would be the same as you would do for a new feature which you can't immediately estimate - schedule a time-boxed "spike" story to find out how to measure and address the problem, then use the results of the spike to improve the accuracy of your estimates.

If the problem you are actually facing is more that the customer thinks the product is complete, but you know there are still bugs, then there might have been a communication problem earlier in the development. This is especially apparent when one or more bugs are very important ("show stoppers"). A robust agile approach should really let the customer know of such problems as early as possible, so that their solutions can be prioritised and scheduled along with the feature stories. In my experience, customers often prioritise such bug fixes higher than many of the features, and thus want them solved before work on lower-priority features is even started.

Does that make sense?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Entering Feature Freeze Phase