a different definition of done for hotfixes?
When emergency fixes are needed there is a temptation among my team to get the fix in place as soon as possible without adhering to all items in our team's definition of done. The argument is that critical production issues shouldn't wait for documentation to be updated or corresponding test cases to be automated. In retrospective conversation it was floated by one team member that perhaps we should have a different definition of done for hotfixes. I'm curious to hear what others in this community think of this.
When technical debt is incurred by releasing this undone work, how is transparency maintained over it, and what policy do the team follow for paying it off?
Thanks for the reply Ian. I interpret your question as a rhetorical one to suggest that it may be acceptable to take shortcuts for hotfixes if the team is transparent about it, tracks the tech debt, and pays it off before it accrues serious interest. Is that an accurate interpretation?
In theory, bugs are bugs because they behave different from the existing documentation. And they are detected, because existing test cases fail.
So theoretically all requirements of the DoD are already met. In practice, there are often adjustments required, but in most cases this can be achieved until the end of the Sprint. It might be a different decision to ship an urgent fix already to a customer before it is completely done.
Does the definition of done represent quality aspects that can be guaranteed by the Development Team, or does it represent steps of a process that aren't always recognised as necessary?