Agile "Hardening Sprint" What Why & When
In today's IT industry, most of the projects follow Agile (SCRUM or KANBAN). During the course of the project mostly towards the tail end or in middle, there is a word that sounds like this "HARDENING" sprint. This is hard to be heard by business as this sprint will not produce a value added release. Rather it focuses on the stability of the app or course correction.
The What:
Hardening sprint as said earlier will not take new requirements from the backlog, rather the story will be app stability or defects to be addressed. This is more or less an technical sprint without any architectural output. The desired output is a more stable working app.
The Why
There are the 3 major reasons for the "Hardening Sprint" to happen
1. More open defects
The "Done" is "NOT Done". There are too many defects open at the given time. Functional and non-functional defects making the application less valued by business.
2. Course Correction
Since, Agile allows to change the stories before the sprint start, which leads to changes to the App behavior or inclusion of new services
3. System Behavior & App Package
Some new or changed features need application architecture change to be implemented. Another significant factor is doing system behavior testing like when web services are down, when App is not upgraded to newer version, the web service to support both newer and older version of the app to be tested by developers and testers for a better customer experience. This will improve the app stability. Last but not the least application package verification might help reduce the app size by removing unwanted codes or modules or images.
The When:
This is good question, usually, when there is new team developing the app, its better to use this after 4th or 5th sprint based on the requirement changes or open defects or App architecture updates
Secondly this can be used as the last sprint before the app launch. In this scenario if the sprint is 2 week cycle, better to have a release every week to ensure the stability is achieved and tested.
The DONTS
Do NOT use this sprint to take the left out stories from backlog, this will have bigger issues in projecting the velocity and release cycle and it will have repercussions from business owners. This needs to be watched out by the SCRUM MASTER
The What:
Hardening sprint as said earlier will not take new requirements from the backlog, rather the story will be app stability or defects to be addressed. This is more or less an technical sprint without any architectural output. The desired output is a more stable working app.
The Why
There are the 3 major reasons for the "Hardening Sprint" to happen
1. More open defects
The "Done" is "NOT Done". There are too many defects open at the given time. Functional and non-functional defects making the application less valued by business.
2. Course Correction
Since, Agile allows to change the stories before the sprint start, which leads to changes to the App behavior or inclusion of new services
3. System Behavior & App Package
Some new or changed features need application architecture change to be implemented. Another significant factor is doing system behavior testing like when web services are down, when App is not upgraded to newer version, the web service to support both newer and older version of the app to be tested by developers and testers for a better customer experience. This will improve the app stability. Last but not the least application package verification might help reduce the app size by removing unwanted codes or modules or images.
The When:
This is good question, usually, when there is new team developing the app, its better to use this after 4th or 5th sprint based on the requirement changes or open defects or App architecture updates
Secondly this can be used as the last sprint before the app launch. In this scenario if the sprint is 2 week cycle, better to have a release every week to ensure the stability is achieved and tested.
The DONTS
Do NOT use this sprint to take the left out stories from backlog, this will have bigger issues in projecting the velocity and release cycle and it will have repercussions from business owners. This needs to be watched out by the SCRUM MASTER
Comments
Post a Comment