Skip to main content

a different definition of done for hotfixes?

Last post 08:24 am February 25, 2018 by Simon Mayer
4 replies
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?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.