Should defects be raised during sprints or just noted in the stories and assigned to developers?

Question

I have heard that when testing stories developed in the current sprint, no issues are raised they are not completed (i.e. definition of done was not fulfilled) and that you should only raise issues when you find another, unrelated issue etc. While it does make sense not to raise issues on something that developers still can work on till the end of the sprint, I fail to find some "best practices". Is that a correct approach?

Answer 1

It depends on your process. In my world, a defect is something that escapes your quality practices. But its up for you to define exactly what those are.

Some processes have a clear separation between the development team and the test / quality team. This is the world that I live in now. The development team is responsible for unit and integration tests and the quality team is responsible for deliverable-level (application and system level) regression and acceptance tests. In this environment, any issue that was not found by the development team in their testing would be recorded as a defect as it escaped the development team's quality activities - code reviews and tests.

The agile methods promote a highly integrated cross-functional team. In this environment, the quality activities also also integrated. Different people may be leading different activities, but everyone's involved every step of the way. Because of that, there's not always a clear hand-off from a development team to a quality team. As such, I would consider a defect to be something that makes it through to the end of the iteration and into the release.

However, something to consider is communication. In my first example, I may note an issue that I find in testing that is minor, but don't have the necessary path to fix in the development cycle. I may log a defect to communicate that I found an issue and allow it to be dispositioned. The project lead or quality team may say that it's actually a big deal (to the customer or from a product quality perspective) and demand it get fixed in the development cycle, or it may be planned for a later release.

In the end, you do need to do the right thing to enable you to understand your product quality and communicate the current state of the development effort to the appropriate stakeholders.

Answer 2

One of the key values of agile development is that you want to deliver working software, which means that it has been verified that the features you are delivering have been verified to be working correctly (according to your team's understanding of the feature).

If you find a problem while testing, then there are a few possibilities:

1. The problem is related to one of the features/stories you are currently developing and is severe enough that you would not be able to deliver the story according to your quality standards if the problem isn't fixed.
2. The problem is related to one of the features/stories you are currently developing and is not so severe that you are still able to deliver the story according to your quality standards if the problem isn't fixed.
3. The problem is unrelated to the stories you are currently developing and doesn't impact them.

In case of #1, you should, as a team, try to fix the problem before the end of the sprint. Otherwise, you won't be able to say that you have finished the work. Whether or not a ticket in the bug-tracking system is needed depends on your local conventions and requirements for traceability.

In case of #2 or #3, the problem should be reported to the Product Owner, so that it can be put on the product backlog and prioritized. Whether or not a ticket in the bug-tracking system is needed again depends on your local conventions and how your product backlog is being managed.
_{(Be prepared that especially items under #2 might get the priority "do when hell freezes over" aka never.)}

Answer 3

The Scrum Guide provides some guidance on this

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”

Therefore, a team practicing Scrum should not knowingly allow the product to suffer unexpected regression of functionality. They should also disallow known defects in new functionality unless the Increment is in a "useable condition and meets the Scrum Team's definition of "Done."

Also

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.

Scrum allows leeway for Scrum Teams to create their own processes for managing work in progress and bugs in production code. This is because there is no "best practice" in a complex domain like most software development. Successful practices emerge as the result of performing experiments and choosing the ones that tend to succeed. More on complexity here.

Enough beating around the bush...HERE'S YOUR ANSWER

Pick a process e.g. log and fix all bugs regardless of when and where they are found and start measuring and retrospecting on the effect of that new process. The team will see pros and cons and will eventually settle on a proven method that works for them within the Scrum framework.

Most importantly, the Scrum Team will have made its decision empirically and in a self-organization manner.