In the final days of a sprint just before a major release, it can be tempting to look for ways to get as many extra features added as possible.  Scanning through the list of known bugs and requested enhancements, the desire to fit in just a few more items from the product backlog becomes powerful, especially when the ‘only’ thing the coders and testers seem to be doing is working on improving unit test coverage and diving deeper into regression test results.  Surely there is still time to add a couple small items that users have requested or to address some of those tiny but irksome issues that have been bothering you for weeks.

Some of those who have been reading this blog consistently have asked if I have only ever seen one movie.  Well, here’s an illustration that highlights the problem with trying to add just one more little feature that comes from an entirely different place: http://www.youtube.com/watch?v=HJZPzQESq_0

While hopefully the attempt to add features at the last minute won’t cause your software release to blow up, there are a few things to keep in mind that will help avoid such explosions.

1. Prioritized planning from a well-managed backlog.  The first key to avoiding such blow ups is working with a prioritized plan for product development from a well-managed product backlog.  Detailed plans for the current and subsequent sprint and a product roadmap of development priorities for the coming months and quarters provides a useful defense against the pull to cram in extra features and fixes at the end of a development cycle.  Flexibility with this planning and prioritization process means that when unexpected needs arise – whether from new market intelligence or bugs found after a release – they can be addressed in a timely manner while continuing to make regular progress toward broader goals in the development of the product.  I know that one of my key responsibilities as a product owner is to regularly review, edit, reprioritize, and revise our product backlog, making sure that it reflects our most important goals.  I need to do this for the current sprint, for the sprint we are planning next, and for the longer-term priorities on our backlog.  When I can point to a solid plan it makes it easier to quell frantic requests for last minute extras in a given sprint.
2. Test locally, regress globally.  As new features are added or bugs are fixed, ideally a coder and tester are first looking at these enhancements in a local environment before they are released to the broader code base.  Errors and unintended consequences can often be caught in this way before they make it into the larger development environment.  Combining local testing with global regression of all features across the code base adds an additional layer of certainty about the stability and interactions of new enhancements.  While 100% coverage through regression testing suites is probably unattainable, the broader the coverage the more confident you can be that development in one area won’t introduce problems somewhere else.
3. There’s always next sprint.  Part of the beauty of the Agile software development method is the frequent short development cycles.  Knowing that things which didn’t make it in the current release can be ready to push out in a few weeks (depending upon your sprint length) takes off much of the pressure to stuff in as many features as possible each release.  If software updates, enhancements, and fixes are only released once or twice a year it becomes much more tempting to fill these deployments with as many pieces as possible.  But when new code is developed, tested, and released in regular short sprints the ability to wait becomes a more realistic option for both developers and end users.

Following these three guidelines and avoiding the temptation to squeeze in one more ‘wafer thin’ feature or bug fix should help minimize the chances that things will blow up when you go to production.  Of course, even well-planned deployments can blow up on occasion because, in truth, it’s not that simple.