I have been reading some threads/articles online but I would highly appreciate some feedback based on my particular case.

The context: a complex sector, historically no QA, large and old legacy codebase + new code based on microservices. Not using Scrum in the intended way, only some of its notions/terms. I am the only newly hired QA per the team of 12 developers.

The problem: while testing specific features in the scope of a current sprint I often find bugs in the legacy code. And nothing comes to mind (that I would like) to track these bugs. Our product backlog in JIRA is not used according to Scrum. We add only the features/bugs that are to be added to the next sprint and that's it. This managerial decision is not discussible.

So far, I can only think of:

  1. creating a separate backlog for legacy bugs (the main con: it will become a cemetery).
  2. Adding them to the product backlog in JIRA but labeling them instantly with a “won’t fix” label/status so that they won’t be visible in the backlog.
  3. When creating test reports for testing certain features, attach a list of found bugs to them (this looks like the past century to me, w/a risk of having several Google docs with bug reports for the same module and missing an important issue)
  4. Try to convince the team to always discuss the bugs found with the devs concerned. The bugs they deem important enough to work on this/next sprint are added to JIRA and the rest are just discarded and never tracked.
  • 1
    If Jira only contains the work for the next Sprint, how is work associated with future efforts tracked and managed? How do product managers keep track of ideas and concepts that need to be refined before they are ready for selection at Sprint Planning? I don't see much of a difference between a defect deferred for a longer time and these longer-term product concepts. The only difference is the level of specificity - a defect report is usually specific and well-defined, while the concepts need to be refined and decomposed into actionable units of work.
    – Thomas Owens
    Commented Apr 18 at 13:10
  • @ThomasOwens In brief, at the top level they follow OKRs, then the actionable units of work are established to reach the objectives, and the Gannt is drawn. Commented Apr 19 at 6:30
  • But that doesn't answer my question. Where are those OKRs and actionable units of work tracked? What tool is used to capture them? OKRs likely have actionable units of work for more than the next Sprint. Where do those go?
    – Thomas Owens
    Commented Apr 19 at 10:48
  • we create corresponding epics in JIRA for large pieces of work (defined and tracked in another system). The PBIs are defined per sprint based on the roadmap and priorities. I guess we could do with some process improvements here as well but project/product management decisions are definitely outside my responsibilities :) Commented Apr 19 at 12:30
  • 1
    This is an XY problem. It may be true that product management decisions are outside your responsibility, but you are responsible for process improvements related to quality assurance and communicating the state of quality of the product or service. I can expand on this in an answer.
    – Thomas Owens
    Commented Apr 19 at 12:37

3 Answers 3


We can set Scrum aside. The organization has not and does not appear to implement Scrum as defined in the Scrum Guide. Using Scrum terms and concepts may be counterproductive at this point.

Instead, we can focus on (software) quality assurance and the outcomes typically associated with performing the (software) quality assurance function. More specifically, we can focus on the activities and outcomes related to product quality and set aside process quality activities.

The activities to focus on include:

  • Evaluating products, services, and associated documentation for conformance to requirements
  • Evaluating products and services for acceptability
  • Measure the quality of the products and services
  • Creating and managing data, information, and records associated with quality assurance activities

To summarize these activities, a portion of software quality assurance involves ensuring that the work done by development teams meets the defined requirements (verification), that the products are usable and acceptable to stakeholders (validation), and measuring and communicating the quality of the product as determined by verification and/or validation efforts.

One problem in the current organization appears to be that there is no way to track defects in the system. This means that even if you do perform verification and validation successfully, some records (defect reports, for example) can't be managed, making it more difficult to provide information about the quality of the products and services.

As someone carrying out quality assurance functions, part of your responsibility is making sure that you have the tools needed to do your job and working with the right people from the organization to build, buy, and configure the tools to carry out the work required.

The organization has a tool that is very well suited to doing what you need. The problem statement says that formalized quality assurance is new to the organization. Outright dismissing what appears to be the best possible solution - configuring Jira to support defect tracking and analysis - is artificially limiting options. As a quality assurance specialist, you should communicate good practices to the organization, helping them improve their quality assurance practices, and ensuring that other practices (like product management) consider the information generated from quality assurance practices.

However, some of your options are good if management doesn't want to improve their processes and tool usage. In order of my preference, if improving the use of Jira is dismissed, I would move on to these options:

  1. Create a separate Jira project for bugs. Even though it may become a cemetery, it will allow you to carry out the activities typically associated with quality assurance. Perhaps you can demonstrate the value of keeping track of work that may not be done in the next Sprint or two and migrate the issues into the primary project.
  2. Discuss the bugs with the team, perhaps considering a zero-bug policy. Although I'm not a fan of discarding bugs just because they won't be fixed, as it precludes generating a known issues list, there is an argument that important issues will keep coming back for discussion. You could pair this with logging and immediately closing the issue for traceability and tracking how often an issue returns.
  3. Document defects in your test reporting. I would expect that the product managers and developers would review these test reports and create issues in their backlog for things that are important enough. You could use these reports to focus the discussions mentioned in 2, which also means you could log and close issues for traceability if you feel that is necessary.
  • Thomas thank you so much for your answer! Yes, I think I will present them the available options, with pros and cons and telling them my opinion as a QA what are the best practices. Commented Apr 20 at 14:41

Welcome to the community!

1:12 ratio? That's rough. Normal is 1 QA to 3-5 devs! I've been in a 1:10 ration a few times. You're going to be very busy!

Anyway, this situation sounds like a transition period. Moving away from a legacy system to a microservices architecture. It can actually be considered "normal" to not fix bugs in the legacy code, since that code will be going away. That's probably why they don't want it reported since they likely no about them and are choosing to not fix them. It's also likely they are not adding new features to the legacy system.

The only caveat would be high priority/high severity bugs that prevent users from using the software, security risk, a bug that takes down production, etc.

I've worked in transitions like this. It can be hard to find bugs knowing they won't be fixed. I've seen two transitions like this:

  1. Build a whole new application in a new architecture that is in a new code repository. To me, this is preferred to start from scratch like this, especially when using microservices. This way, once the new feature/API is built, the legacy system can call it fairly seamlessly.

  2. Rebuild in place. This is not preferable as you're using the same code repository for the new as the legacy. Unfortunately, this is quite common as leaders see this as a "faster and cheaper way" to rebuild the architecture.

Every time I've seen this, it takes longer and costs more than anticipated since you'll be running into issues in the legacy system. From my experience, it's faster and more cost-effective to use option 1! A lot of the time, legacy systems are buggy, using out-of-date dependencies, have bloated features, etc, so starting from scratch, and fixing them will create a lot of unknown side-effects.

This managerial decision is not discussible.

Well, I'd still approach leadership with the question of "why?" Not to convince them to change their mind, but to gain clarity/understanding into the decision that was made before you joined the team.

From your options, I'd likely choose the first option to notate legacy bugs in a separate bug backlog (bug cemetery), even if that's outside of Jira and in a document. This way, if you come across that bug again, you know you've already found it and self-reported it.

  • 1
    Thank you so much Lee. I appreciate sharing your experience and advice! Luckily, the team chose the first path (new repo, etc) and I can't be more happy about it. I think the decision about almost empty backlog was done to avoid clattering it with things that won't be worked on in the near future, priorities here can change quite often, especially if a major customer wants/complaints about something, so to avoid the constant backlog grooming, they preferred to keep it clean. Seems to be working so far. Commented Apr 19 at 6:42
  • 1
    Not sure why this was downvoted - it's a good answer!
    – dvniel
    Commented Apr 19 at 10:51
  • Thanks @dvniel. I'm not sure why it was downvoted 2x either since it addresses the issue from the OP and comes from my own experiences.
    – Lee Jensen
    Commented Apr 19 at 17:47
  • @ElenaKirova You're welcome! I'm glad they chose to use a new repo. That helps so much! Not having clutter also helps keep teams on focus, so if not having legacy bugs reported does that, then I say it's a good enough process/policy. Good luck!
    – Lee Jensen
    Commented Apr 19 at 17:56
  • Also, thanks to anyone who has upvoted this! I appreciate you!
    – Lee Jensen
    Commented Apr 19 at 18:15

You can create an automated check that exposes the bug. And, instead of invalidating the build, it sends an email/message to the developer about the possible problem.

This way people will be continuously warned about the issue.

Continuous, explicit, and specific alerting.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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