There'll be a variety of opinions on how to construct a definition of done (after many years I've never seen two definitions that looked the same). So take what I have to say with a truckload of salt.
On teams that I work with, these types of blockers (or more specifically the absence of critical issues) are always included in the definition of done.
For context, it's common that the first thing on our definition of done checklist is "It is running in production, without a feature flag". We don't consider work on a story to be "done" until it's been running in the real world for some time, and cannot be toggled off.
Applying that to your scenario: If a story introduces a critical bug prior to making it to production, it's not even close to done. It goes right back into the development column, with new acceptance criteria surrounding the issue that was discovered.
Now, there's always a grey area when dealing with non-critical issues. Ultimately it's up to the team, the product owner and the business stakeholders to decide if it's ok to ship code that contains issues that will be fixed some time in the near future.
Typically when we discover any issue within a story, we'll sit down with our product owner and replicate the issue for them. From there we have two options, add new acceptance criteria to address the issue or create a separate (but dependent) bug card to correct the issue.
As I described above, in the case of breaking changes, there's no debate, the card goes back into development. But in the case of a smaller impact issue it's a coin flip, and ultimately up to the product owner and business' best judgement.
I think the only applicable answer you're going to find to this question is going to come from within your team and business context. For example: If you're working on a product that hasn't been released to the public yet, then introducing breaking changes is a far smaller issue than if you were out in the wild with millions of users. That's only one of many variables that will influence how you define when work is "done" in your team.
Yes, having the PO or stakeholders seemed like the best option to me as well.
I wanted to see if others share this view (or if they have reasons to be against it).
Thanks for your input.
P.S. Regarding what you said about having the implementation in production for a while, I just want to say: That's awesome! And badass!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There'll be a variety of opinions on how to construct a definition of done (after many years I've never seen two definitions that looked the same). So take what I have to say with a truckload of salt.
On teams that I work with, these types of blockers (or more specifically the absence of critical issues) are always included in the definition of done.
For context, it's common that the first thing on our definition of done checklist is "It is running in production, without a feature flag". We don't consider work on a story to be "done" until it's been running in the real world for some time, and cannot be toggled off.
Applying that to your scenario: If a story introduces a critical bug prior to making it to production, it's not even close to done. It goes right back into the development column, with new acceptance criteria surrounding the issue that was discovered.
Now, there's always a grey area when dealing with non-critical issues. Ultimately it's up to the team, the product owner and the business stakeholders to decide if it's ok to ship code that contains issues that will be fixed some time in the near future.
Typically when we discover any issue within a story, we'll sit down with our product owner and replicate the issue for them. From there we have two options, add new acceptance criteria to address the issue or create a separate (but dependent) bug card to correct the issue.
As I described above, in the case of breaking changes, there's no debate, the card goes back into development. But in the case of a smaller impact issue it's a coin flip, and ultimately up to the product owner and business' best judgement.
I think the only applicable answer you're going to find to this question is going to come from within your team and business context. For example: If you're working on a product that hasn't been released to the public yet, then introducing breaking changes is a far smaller issue than if you were out in the wild with millions of users. That's only one of many variables that will influence how you define when work is "done" in your team.
Yes, having the PO or stakeholders seemed like the best option to me as well.
I wanted to see if others share this view (or if they have reasons to be against it).
Thanks for your input.
P.S. Regarding what you said about having the implementation in production for a while, I just want to say: That's awesome! And badass!