Teams will often schedule a "hardening sprint" at the end of a release. The purpose of the hardening sprint is to add a level of polishing and testing to the game that doesn't normally occur every sprint. An example of a hardening sprint task is to conduct an eight hour smoke test of the game to catch any problems that don't occur when the game is played for a few minutes.
Unfortunately the hardening sprint can end up becoming a dumping ground for work that should be done every sprint. This should be avoided as it postpones the team and customers from evaluating the value features that should be emerging every sprint.
I like to think of a hardening sprint the same way I think about detailing a car. I have a couple of sons, so I’m often cleaning out rocks and once living organisms they collect and forget weekly. Every month I’ll pull out the shop vacuum, rags and hose to give it a quick cleaning.
Every several months I’ll treat myself to getting the car detailed. I’m always amazed at how the detailers will clean out every nook and cranny in the interior. They even clean out the dirt from areas as obscure as the folds of the boot at the base of the shifter. Of course a week later all evidence of this cleaning is gone.
I don’t polish the shifter boot once a week. I don’t have the time or the need to clean to that level so frequently. On the other hand, I don’t put off cleaning out the rocks and wildlife from my car for the detailers. I don't think they'd appreciate cleaning out mummified frogs.
A hardening sprint at the end of the release is like having your car detailed. It’s important that it only be thought of as the extra bit of polishing detail that you don’t do every sprint. It shouldn’t be a dumping ground for bugs, tuning and stand-in asset work that should be tackled every sprint.
So don't leave the dead frogs for the hardening sprints!