Delivery
Quality, bug triage, techdebt
As a product team, manage quality, bug triage and technical debt through risk, metrics and explicit investment decisions.
Quality competes for resources with new capabilities only when its impact is not translated into the language of the product. Link bugs and tech debt to user losses, incident risk, speed of change, and cost of support – then the priority decision becomes managerial, not taste.
Why Quality Is Critical in Delivery
Definition: Quality in the product
Product quality is not only the absence of bugs, but also the compliance with user expectations, stability, performance and safety. Delivery-team is responsible for ensuring that the outgoing release works as promised, does not break the old functionality, does not add new tech debt and allows the product to live on without rough compromises.
An example of business impact
On real projects, even a couple of bugs in critical features can not only alienate users, but also complicate the life of support, slow the introduction of new features and increase the cost of fixing errors in the future. For example, the growth of bugs at the release stage often leads to additional negotiations with customers and deadlines.
Bug Management: What is a Bug Triage
How the bug triage works
Bug triage is a systematic prioritization of all errors found. The goal is to understand what to repair urgently, what to postpone, and what not to touch at all. The bug triage process involves developers, testers, product and sometimes support.
Typical scheme: Every week or after the testing phase, a short call is held to discuss:
- Description of the bug, consequences
- Critical for the user and business
- Impact on the stability of the release
- Priority of correction
Example: What a bug triage looks like
The team found 23 bugs after the feature release. Of these, three are critical (block payment), five are medium (small UX), the rest are not critical for business. On the triage decide: three urgently fix, part to save in the backlog, on details - in the next sprint, and leave something for a delayed correction.
A strong team maintains a registry of bugs in a system such as Jira, Notion, Linear. Bugs should be closed purposefully, not accidentally.
How the Atlassian bug triage process works
Technical debt: how not to lose control
What is tech debt and why does it accumulate
Technical debt is the compromises in code, architecture, and infrastructure that are made for the sake of speed of delivery today, but require a return to them in the future. If you ignore them, the product begins to degrade: the cost of changes, the number of bugs and the complexity of support increases.
Tech debt can be explicit (old solution, crutch, temporary plug) and hidden (for example, outdated dependencies).
Management of debt and anti-patterns
For tech debt, you can reserve a portion of capacity, but the share should follow from risk and product type, not from universal interest. Critical debt is included in normal prioritization; small improvements are often cheaper to do alongside the changeable code.
A typical mistake is not to allocate tech debt of separate time and not to start tasks (everything remains in the minds of developers), which leads to a snowball of pain after 2-3 releases.
How to track the quality and reduction of debt
Key metrics
For quality control and work with technical debt in the field of Delivery, usually look at:
- Proportion of bugs in testing and sales
- Mean Time to Recovery (MTTR)
- Number of bugs per 1000 lines of code (or per release)
- The number of technical debt cravings in the sprint and their closure
The exact numbers depend on the market and the maturity of the product. Benchmarks on the industry can be found in public reports of QA teams or repository analytics on Github.
Example: Introduction of automatic metrics
The product team introduces defect categories, uniform severity levels, and reaction time tracking. It doesn’t improve quality anymore, but it does allow you to see where the queue is getting older and which components are creating repeated problems. The next step is to link the reasons to the owners and check the change over multiple cycles.
Useful tools: Jira, Linear, automation through GitHub Actions to collect statistics.
Organization of quality delivery processes
Role of regulations, checklists and gates
Good practice is to use acceptance checklists before laying out, implementing pull request review, code freeze and fitogle at the release stage. This blocks critical bugs and prevents unmanageable tech debt from entering production.
Example of application
The company introduces a pre-release checklist for key scenarios, monitoring, known defects and rollbacks. On retro releases, the team notes which items actually caught the problem and removes formal checks. The effect is measured by the severity of incidents and recovery time, not by the number of ticks.
Atlassian Community Quality Checklist
The main mistakes and how to avoid them
Frequent anti-patterns
- Minimize the bug triage or maintain it formally
- Ignore low-priority bugs that become critical
- Do not allocate a separate budget or time for debt
- No transparent quality metric
- Lack of a single registry of bugs and debt
How to act
Formalize the bagtriage, fix everything that has accumulated, implement separate tasks for tech debt, track successful and unsuccessful releases using metrics. In practice, it’s important that processes don’t become bureaucracy, but give the team real value.
FAQ: Questions and answers
Why a bug triage if bugs have priority in a Task Manager?
Priority is often vague and without business emphasis. Triage allows you to reconcile the importance of bugs in the current business context.
How do you know if tech debt is out of control?
The release deadlines are growing, the number of bugs for the same changes is increasing, the team is more fixing the old than creating a new one. It is worth tracking these trends on sprints.
Who should initiate the bug triage?
Responsibility for starting a bug triage is usually on the product or team lead, with all key team members involved.
Is it possible to get rid of tech debt completely?
Nope. The main goal is to keep it within a controlled level so as not to slow down the development of the product.
What bugs do not need to be fixed immediately?
Those that do not affect the main users, do not disrupt business functions, do not result in data loss or block business processes.
Which metric is the easiest to implement for quality control?
Start by tracking the number of bugs per release or MTTR (mean time to recovery) for critical bugs.