When You Discover Done is Not Actually Done

Teams should try to improve the Definition of Done for each increment, so that the quality of the product can improve with each release.

Setting the quality bar higher may mean that additional work must be undertaken if the product is to henceforth meet that standard. In other words, new "undone" work might be recognized as needing to be completed if the quality gap is to be bridged in future increments.

This new work must be included in the Product Backlog and estimated. Features that were once thought to be complete may therefore need to be included again. In this case the estimate given to each of them should reflect the new work needed to meet the revised Definition of Done. These are therefore effectively new items on the Product Backlog.

The team completes a story according to the agreed-to DoD. The business confirms that all acceptance criteria have been met, and gives its blessing. The sprint is closed.

Later, a flaw/bug/oversight is identified with the original story. That effort is over and done with. A new story (or stories) needs to be created to address the issue, and prioritized accordingly by the business for a future sprint.

The retrospective can serve as a good forum for analysis in determining root cause. Was the functionality tested appropriately? Were assumptions made that ultimately turned out incorrect? Was the acceptance criteria insufficient?

Note that the Product Backlog is not limited to contain User Stories. It can also contain bug fixes that can be prioritized by he PO.

Interesting, we are struggling with this issue.

Ian, if I understand correctly you are saying: Dev team: "We just found that last sprints' story crashes the application when doing flow X. So we go to the PO and tell him: we just found a bug, is it important enough to uproot the current sprint? Or do we place the bug somewhere halfway in the backlog so that it never gets solved, as the PO usually has other priorities"

What about having a Definiton of Done that says something about technical debt, or the amount of bugs? As an empowered dev team member, taking pride in my product and fixing this is pretty high on my list of priorities. As a 'scrum anarchist' I would say: the PO can tell us what new things to work on, but we choose how to build it. And part of how is limiting technical debt and open bugs.

So Sanjar, I would suggest: if it is a bug that can be solved in about 2 hours, just fix it, this saves a lot of discussion. If it will take a day or more, you should discuss it with the PO. We currently work as follows (but I doubt this is Scrum);
- Bugs found on stories which were in this sprint, are fixed in this sprint
- Bugs found on stories from earlier sprints are solved next sprint (PO has no say in this)
- Feature requests are planned in the next sprint as the PO requests
The storing of bugs until next sprint is too bureaucratic for my liking (as a tester ;), and they tend to pile up fast. I think Lean (wher the roots Scrum lie) propagates a fix it now and fix it good mentality.

> Ian, if I understand correctly you are
> saying: Dev team: "We just found that
> last sprints' story crashes the
> application when doing flow X. So we go
> to the PO and tell him: we just found a
> bug, is it important enough to uproot the
> current sprint? Or do we place the bug
> somewhere halfway in the backlog so
> that it never gets solved, as the PO
> usually has other priorities"

If it is a defect and it can be fixed in the current Sprint without imperilling the Goal, fix it, along with the Definition of Done.

Otherwise the flow that exposes it represents a scope increase that cannot be absorbed. The flow must therefore be accounted for on the Product Backlog so that an improved Definition of Done can be satisfied. Whether it is called a defect, bug, or user story is immaterial. It is work to be done. It should be placed at the very bottom of the Product Backlog because the PO has not yet had the opportunity to prioritize it relative to everything else that has to be done. Priorities of backlog items should be determined by the PO based on the relative value that is likely to be delivered.