Hardening Sprint?

Where did you read this?

Every Sprint should deliver a potentially releasable product increment. If team needs a separate Sprint before the product release then we haven't understood the concept of Scrum and Sprint.

I don't mind keeping some technical debt but will prefer re-paying it on regular basis. We should not accumulate it so much that we need a dedicated Sprint for it.

It's one question in the simulation exam by Mikhail Lapshin (and I guess one of them on Management Plaza too) and of course the answer is no, there is no hardening Sprint in SCRUM.

But what do "hardening sprint" and "technical debt" mean?

> But what do "hardening sprint" and "technical debt" mean?

Technical debt refers to the long-term consequences of poor design decisions.

- Can you see why the metaphor of "debt" is used to describe this?
- If technical debt is allowed to accumulate over multiple sprints, can you see why a "special" sprint (e.g. a so-called "hardening sprint") might be thought necessary in order to remedy the poor decisions that were made?
- Each sprint should produce an increment of release quality. The decisions made should be fit for purpose and technical debt should thus be limited. Can you see how "hardening sprints" might encourage significant technical debt to be incurred in the first place?

Very well explained @Ian.

IS it safe to say that some examples of technical debt are the following:

1. Poor Architecture that leads to performance issues
2. Selection of incorrect technology/ language?
3. Not using best development practices?
4. etc
5. etc

Robb

Yes

Thank you.

FALSE. It is not normal. Scrum Teams deliver an Increment of product functionality every Sprint. This Increment is usable, so a Product Owner may choose to immediately release it. So, there is nothing to prepare. Each increment contains only “Done” functionality that could be released immediately.