Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Entering Feature Freeze Phase

 
Ted Young
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic