This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Entering Feature Freeze Phase

 
Greenhorn
Posts: 10
IntelliJ IDE Spring Java
  • 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
 
(instanceof Sidekick)
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?
 
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?
 
"I know this defies the law of gravity... but I never studied law." -B. Bunny Defiant tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!