Hardening sprints in SAFe: how to add value to the project without coding and testing

As we mentioned earlier, SAFe divides the development timeline into a set of five sprints within a Program Increment (PI). However, that is not 100 percent true. There are four full-fledged sprints and a HIP sprint at the tail end of the series.

In this article, we’ll outline the HIP sprint purposes, values, and prospects from the point of view of QA.

What does NOT happen during the HIP sprint?

Ideally, coding and testing should be terminated before the HIP sprint kicks off. So there should be no developing and testing activities during the HIP sprint.

Then what?

The sprint title stands for hardening, innovation, and planning. Each of the components gives us a hint about the purposes of the HIP sprint.

• Hardening: Ensures that all PI objectives are achieved, and technical debt is reduced. Time is given to go through checklists again and demonstrate Potentially Shippable Increment (PSI) to stakeholders.
• Innovation: Provides time for teams to turn up to a hackathon, pitch new ideas, or introduce some innovations.
• Planning: Conducts Retrospective and completes the planning of the next PI.

HIP sprints in QA: no time for innovation. Why?

No doubt, HIP sprints provide great opportunities for creative guys to offer any new ideas and even try to put it in place. However, as for QA, reality is a bit different.

Most often, we use this time to finalize all tests that were left behind in the fourth sprint. The reasons why the tests weren’t complete in time vary: features delivery was halted, the number of defects grew, or there might arise one blocking defect that prevented the team from doing their job.

If the product release is around the corner, the QA team will be busy running final performance and integration tests that couldn’t be conducted before as every team was committed to their own user story.

It goes without saying that developers do enjoy greater opportunities during the HIP sprint.

But nothing is impossible, and we also managed to make time and think about the future. Developing automated scripts with the client’s data is what we were engaged in during the HIP sprint. These tests were launched every time before the service pack was delivered to the production.

Test automation enabled us to save about 30 hours of manual testing every two weeks. Moreover, automated tests help to increase test coverage: now we could apply them for every client, not for the single ones, as we did before.

That’s it! As you see, the HIP sprint is not a myth, but quite a real thing in SAFe. And while there’s no new functionality delivered, it brings great value to the project.

Now it’s your turn to speak up! Have you tried HIP sprints in SAFe? If using Scrum, how do you allow time for hardening and innovation activities? Please share your thoughts in the comments below.