3

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?

  • 2
    Can you make your question more specific, perhaps by providing an example of what you mean? – Robert Harvey Nov 20 '15 at 14:25
  • I thought it was clear - should defects be raised during sprints or just noted in the stories and asigned to developers? – Pietross Nov 20 '15 at 14:28
  • It's the phrase "While it does make sense not to raise issues on something that developers still can work on till the end of the sprint" that is confusing me. Do you actually have free time in a sprint to work on such things? In our shop, we have a fast-track process for urgent things that need to be done during the same sprint. I doubt you're going to find canonical advice on this, though; the needs of the business outweigh any notion of "correctness." Those needs have to be balanced with discipline. – Robert Harvey Nov 20 '15 at 14:30
  • Well what I meant is - during the sprint, stories are considered done when DoD is fulfilled. Also during the sprint, developer can stll fix the issues as part of development and therefore raising issues does not make sense to me, if related to functionality being implemented. – Pietross Nov 20 '15 at 14:38
  • Seems to me like you should raise an issue if your sprint task is going to be blocked in some way, and you are going to be unable to complete the task during the sprint. – Robert Harvey Nov 20 '15 at 14:47
5

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.

3

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.)

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.