In IT, hardening is typically the method of protecting a system by which its vulnerability surface, which is larger when a system performs more functions; a single-function system is, in theory, more stable than a multipurpose system.
What is a Hardening Sprint? Some Scrum Teams build applications of such poor quality that they want to spend a whole sprint enhancing Product Increment quality to an acceptable level. What that means is that their previous sprints did not produce enough consistency and that action was accepted inappropriately.
Scrum Teams should spend each sprint improving their technical designs and implementations and should aim to reinforce their DoD to enhance their output further. There is no such thing in Scrum as a Hardening Sprint or a sprint which only checks the Product Increment. If they do occur, these are dysfunctions and the Scrum Master can collaborate with those on the Scrum Team to eliminate these dysfunctions. Rather than running a Hardening Sprint, what Scrum Teams can do is to be intolerant to any lowering to their quality targets just to complete the products. Scrum team needs to keep its sprint goal. Instead, if they are faced with such a dilemma, they can renegotiate what they’ll do in a sprint so that whatever they do still meet the sprint goal. They must hold, their Definition of Done. Also, they could build a new Product Increment which could be released into the production environment if the Product Owner so desired. Anything less than that is a dysfunction. However, if a Scrum Team continues to spend a whole sprint testing of the Product Increment before bringing tier improvements into the production environment, this means that the Scrum Team has neglected to test the software adequately during each sprint. The Product Increment should be completely checked in each sprint, so if the Product Owner desired to release the code into production, they could do so with confidence without further testing. Scrum Teams using sprints to do nothing more than test their code use Scrum-fall, a mix of Scrum project approaches and waterfall approaches. It is not about Scrum.
Last but not least remember, every sprint must create at least one piece of usable functionality.
Thanks for reading the Scrumsaturday.com! Take a minute to follow me on Twitter if you enjoyed this post and want to see more.
Most commented