HIP sprints with SAFe and specialized sprints with Scrum
One of the heatedly discussed aspects of SAFe(Scaled Agile Framework) is the specified HIP sprints. HIP here stands for Hardening, Innovation and Planning. In earlier…
One of the heatedly discussed aspects of SAFe(Scaled Agile Framework) is the specified HIP sprints. HIP here stands for Hardening, Innovation and Planning. In earlier versions of SAFe, this was still called Hardening Sprints.
In Scrum implementations, we usually view the need for a stabilization phase with a fair amount of suspicion – after all, it almost always goes hand-in-hand with a poor code base and suboptimal development practices. Therefore, these Hardening Sprints have also caused quite a sharp reaction in the Scrum – community (also from me).
Now I have noticed that this point of criticism has at least been put into perspective – for me this is not only true because of the renaming
- In a large development, the individual Scrum team must guarantee higher planning reliability than in an autonomous environment. Planning reliability must be bought with a buffer. This is the first application for the HIP Sprint.
- All Scrum teams are involved in a rough planning of the cadence of 3-4 months, defining “objectives”, i.e. goals they consider achievable and “stretch objectives”, i.e. things that will only be achieved under optimal conditions. Scrum teams prepare for this big joint planning meeting, which is the second goal of the HIP Sprint
- Third, the HIP Sprint is the period during which experiments, learning activities, and the like are conducted – across the board: Innovation. When the team has completed the other two activities, this is the built-in reward for effective and well-planned work.
Going back to pure Scrum, one thing remains the same: the need for stabilization sprints indicates weaknesses in the previous sprints: the result of a sprint should be software of deliverable quality.
However, special sprints have always been discussed (and sometimes hotly disputed) in Scrum as well:
- Sprint 0 for initial planning, possibly also for calibrating the expected velocity.
- A product owner is expected to compile the backlog items in such a way that they can be used to designate nameable increments for the sprints – if you look at it closely, these are also specialized sprints.