This is my ninth post in “Agile Program Management” series. Hardening Sprint is a familiar term for most practitioners. However it is a frequently misunderstood term too. Typically an iteration or Sprint that is at the end of all Sprints in a release cycle is planned in such a way that team members focus on (and only on) hardening activities. When this is true, we call it a hardening Sprint.
In one of my earlier posts I discussed about how procrastination makes Hardening Sprints harder.
Agile Program Management is a complex function as it involves program managing multiple related projects. Not understanding the significance of hardening Sprints can lead to
- Incorrect decisions or expectations on accommodating new features in hardening Sprints,
- Delays in release timelines because of unexpected issues in one or more applications or products in spite of (or due to) hardening activities
- Procrastination and last minute surprises that indicate risks related to product or application quality
For this, those who are involved in Agile Program Management function need to understand what constitutes a hardening Sprint. Also they must establish a common understanding on what constitutes a hardening Sprint across project teams.
For example, SAFe suggests HIP Sprints. HIP stands for Hardening, Innovation and Planning.
Hardening Sprints are to stabilize code or to meet release level ‘Definition of Done’.
Hardening Sprints are not to be seen as an opportunity to ‘relax’ or ‘dilute’ the ‘Definition of Done’ at user story level or Sprint level in all previous Sprints with a misunderstanding that all those can be accumulated as technical debt and paid off during Hardening Sprints. When this happens we miss the essence of Agile. This approach defies demos or reviews and retrospectives. This does not lead to delivering 'potentially shippable' increments or user stories at the end of Sprints.
Also, feature implementation or enhancements (new user stories) are not part of hardening Sprints.When Agile Program Management teams understand these, they develop the capabilities to ask powerful questions when they look at release plans or when they govern the progress of Sprints. Besides, when things go wrong during Hardening Sprints, they do have enough awareness to deal with the situation and demonstrate their value to teams.
Hardening Sprints do not add much to the overall productivity or velocity of the team in terms of their ability to deliver new features. In other words, the quantum of efforts spent in Hardening Sprints do not add new features and corresponding Story Points to an upcoming release. Hardening Sprints improve the stability and maintainability of releases, and ensure that that code base is good to launch a release.
To conclude, let me put forward some questions. When you review a release plan and find that there is no hardening Sprint, what are you going to do about it? Also, when an hardening Sprint is approaching in your release road map, what kind of questions will you ask to figure out if your teams are moving in the right direction? When there is business pressure to accommodate all product backlog items very tightly into multiple Sprints and deliver releases, how will you negotiate to budget for a hardening Sprint per release?