Hardening Sprints - Scrum Anti-Pattern or Necessity

First, the term should be clear. For the past decade, there has been talk of "Hardening Sprints." Many supporters of Scaled Agile Framework advocate the concept. They see the Hardening Sprint and its conceptual companion - the Stabilization Sprint - as a kind of anti-pattern in Scrum, because this practice actually goes against the essence of Scrum. At the same time, they champion the Agile Manifesto and Scrum Guide in a very literal way. Hardening Sprints are basically an approach found primarily in companies where bug fixing is postponed until the very end of the project. The advantage that proponents see in this is that teams can complete their Sprints and move on to the next Sprint at a time, knowing full well that there will be another Hardening Sprint at the end of the project, so they can return to any point in the project at the end. Only then do they do regression integrations, third-party testing, and end-to-end testing.
As a result, some view these Hardening Sprints as work that is simply postponed but does not itself add value.

How did these Hardening Sprints develop? They are common in many larger companies in the IT industry, where the Scaled Agile Framework has been introduced, with a team of eight to ten people working simultaneously. In each of the Sprints, some of which run in parallel, a piece of functionality is worked on - until the system is ready for hardening or until the developers still need stabilisation before a release. 
In the earlier agile concepts, innovation, hardening and planning Sprints were always firmly scheduled at the end of a project. Only since SAFe 5.1 has the need for such so-called HIP Sprints no longer been seen. The reason for this was DevOps and continuous development approaches. Today, the Scaled Agile Framework no longer provide for such Sprints, but there are still similar concepts. In Large Scale Scrum, there are Sprints that are supposed to deliver products that are potentially shippable, meaning they correspond to done. In the DA, Disciplined Agile methodology, it is left to the teams to find the most appropriate methodology and here Hardening Sprints are explicitly not excluded. The dynamic system development method, DSDM, is a more project-oriented technique with rapid application development that decides what should and should not be included in the product only when a firm project deadline is known. Nexus can also be mentioned here. Here, an integration team is stretched across several Scrum Teams. This ensures that the integration already takes place during the Sprints, instead of in a Hardening Sprint, which is, however, definitely open as an option.

The exact definition of done is of great importance. When a Sprint is done is usually closely related to how much remaining work is left. This remains for the Hardening Sprint. Those who work with a story card in the team like to declare a Sprint done, even if it is clear that minor errors will appear in production and have to be dealt with. However, there are also much stricter definitions of done, for example, when all requirements of a story card have been fully implemented and also already tested. Basically, however, all teams work to complete a Sprint with as little residual risk and work as possible. This keeps the backlog lean and reduces the need to do a Hardening Sprint.

A team that accumulates more residual work ends up taking more time to actually complete the project. One problem with Hardening Sprints is that everyone working on the troubleshooting at the end also needs to get back into the problem. So often, more time is needed to fix bugs during a Hardening Sprint than it would take to fix the same bug immediately. So these technical debts demand an interest. Large teams often have leeway for a looser definition of done. Small teams rarely have that option. And that's the point of Scrum: to deal with an issue in the actual Sprint and get as done as possible.

So how do you avoid Hardening Sprints at the end of a project? One idea is to reduce user stories by breaking down a requirement with multiple scenarios and conditions. Create a minimum viable product, rather than half-doing all the requirements and saving them for later. Prioritize where appropriate. Leave under borderline cases out of consideration. 
In short, design Sprints to meet their requirements so that the end result is a product that can be tested by QA. Everything else comes in the next iteration. Another approach is spillover work. If a team determines that it is impossible to meet the requirements in the current Sprint, the work can be split between that Sprint and the next Sprint to carry non-critical defects out of a Sprint. Out-of-cycle processing is also an option. Spillover work allows teams to decide how much slack to give themselves and when to include a new story in a Sprint.