Hardening Sprints
Hardening: What Is It?
Hardening is that special time of a project (usually 2 - 3 weeks) before sending it out to the world. Generally, a project is ready for hardening after is has become feature complete. However, hardening sprints do not and should not be limited to right before final delivery. It can occasionally be leveraged in between feature sprints to allow time for the team to definitively say that what has been done is really done, and QA plays a crucial role in determining that.
What Is QA's Role?
Up to this point, QA should have completed at least one pass on all areas of the project and reported the bulk of the defects that exist on the project. However, it is improbable, nay impossible that all defects have been found since the project has been in an ever changing state. QA will complete a new sweep in a stable environment, and then retest defects sent back to QA as fixed.
The Process
When a project goes into hardening, a code freeze should take place on the staging environment and it should remain unchanged during the initial QA sweep. It is important to discuss a build schedule with the team, and make sure everyone is inline. Generally, it is good to get a new build with old bug fixes immediately after completing the sweep to begin retesting as soon as possible. Future builds should be delivered based on how quickly the Dev team is able to implement fixes.
The PO should take charge of triaging the defects, moving and assigning them into this sprint or placing them into the backlog for a later sprint. They will continue this process with any new defects discovered during the hardening sweep.
In the first phase, the Dev team will begin addressing the defects that have been found before hardening, while QA will start a new sweep in the stable staging environment rounding up the remaining issues.
After the Devs complete their first round of fixes and QA has completed their sweeps the next phase begins. The fixed defects are sent to QA to verify and the Devs begin working on fixes for any new defects found during the hardening sweep or any old issues that were verified as still open.
Finally, the Devs finish up their fixes and send to QA for one last check.
Ideal Schedule
- Day 1 (Code Freeze)
- PO - Move/assign old bugs to be fixed into Sprint
- DEV - Provide New Build that is feature complete
- Week 1
- QA - Full Sweep. At this time new bugs will be found
- DEV - Fix previously reported bugs brought into the Sprint by the PO
- Week 2
- PO - Move/Assign New Bugs into Sprint
- DEV - Deliver New Build with old bug fixes
- DEV - Begin Fixes for new bugs discovered in sweep
- QA - Retests old bugs
- Week 2 (Repeat till all defects in Sprint are done)
- DEV - New Build with new bug fixes
- Delivery time is flexible, but should be communicated as early as possible as to when a new build will be ready for QA
- DEV - Fix any regression or Verified Open bugs
- QA - Retest new bugs, regression, and any Verified Open
- DEV - New Build with new bug fixes