There are occasionally some odd situations that transpire during the Agile planning process, and one question that frequently arises is how to stay releasable when certain features cannot be broken down into releasable code prior to the ship date. Ideally, the basic Agile tenets are observed before starting to classify something as out of the ordinary: nightly builds of fully installable and executable software, small increments of working software delivered (2 weeks), continuous testing, and etc. Even if a team is following all of these, there can still be some situations where the team cannot complete a feature to a point where it can be delivered to a customer. This could be a situation where the small increments of the feature, while working independently, do not add up to enough value to complete a useful workflow, or the team may have incorporated some 3rd party tool or product, which instantly overwhelms the team with integration test cases. In these rare cases, teams are left with the question of how do we keep the software releasable but continue working on features which may not make it to the customer’s release. The following list provides some ideas to combat this problem:

• Hide the functionality. This option could include several things such as hiding a tab (via configuration or unreferenced URL) with the incomplete functionality, but allowing access to the product owner, developers, and QA, so that testing can occur in the main branch of the software. It could also involve licensing, where a license key prohibits the customer from accessing the uncompleted parts of the product.
• Wait on delivering the 3rd party product. Even though the team may have spent vast amounts of time implementing new APIs and testing the new product during the release, the incorporation of the new 3rd party product should be constructed such that it does not prevent the rest of the product from shipping.
• Limit the selling points. While it’s never a good idea to have visible parts of the product which are not fully usable by the customer, the important point is to make sure the rest of the product continues to function properly. If other useful parts of the code can be delivered to the customer, the customer may want to take advantage of the other fully working functionality, and this is what should be promoted.
• Document unfinished workflows. As with the option above, release notes and known issues can documented where the product is lacking. With both of these last two suggestions, the limited functionality should not create additional problems nor allow the user to sabotage himself.