a different definition of done for hotfixes?

Last post 08:24 am February 25, 2018
by Simon Mayer
4 replies
Author
Messages
05:34 am February 13, 2018

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.

11:05 pm February 13, 2018

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?

06:16 am February 14, 2018

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? 

 

12:08 pm February 23, 2018

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. 

08:24 am February 25, 2018

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?