Bugs and root cause, answered in full.
What happens when something is wrong: raising a bug somebody can act on, and finding the cause rather than the symptom.
- questions in this group, each answered in full
- 8
- pages the answers are written on, every one linked
- 2
- questions across the whole FAQ
- 316
8 questions on bugs and root cause, answered by Tenhaw, a UK AI consultancy and AI delivery partner based in London. Nothing here is a summary: each answer is the exact text from the page that owns it, and every group links back to that page for the context around it.
How to raise a bug
Answered on How to raise a bug, and rendered here in the same words.
Read the page these answers live on →
Is a missed requirement a bug?
No. If nobody approved the behaviour being asked for, nothing is defective, the product is doing what was agreed. That is new scope: a story under an existing epic, or a new epic carrying its own share of an outcome's value. The test is whether you can link to an acceptance criterion, user journey or test requirement that the live behaviour contradicts. If you cannot produce that link, you are raising a change request wearing a bug's clothes, and the bug budget will lie about quality all quarter.
Do defects found before release count against the bug budget?
No. A story in progress or in review that does not meet its acceptance criteria is not done, so send it back rather than opening a bug. The same applies in an AI-native team when a test requirement in the outcome ticket fails before release. The bug budget forecasts what escapes into production, and polluting it with in-flight rework destroys the one signal it carries. Track pre-release rework, if you want it, as its own measure of how well work is being written and reviewed.
Who sets severity, and can it be changed?
The reporter sets an opening severity against the published rubric, because they have seen the impact. One named person, usually the product manager who owns the parent outcome, is allowed to change it, and the reason goes in the ticket. Set the rubric on user and revenue impact, never on how loudly the request arrived. Severity decides three things: whether the bug interrupts the current sprint, whether it triggers a rollback conversation, and whether it earns a root cause analysis, so an inflated S1 costs real capacity.
What do we do when the bug budget runs out mid-quarter?
Raise it at the next monthly health check and treat it as a forecast that has broken, not a cap you have breached. S1s still interrupt the sprint, because a budget does not make revenue exposure acceptable. What changes is the planned work: something in the quarter gives way, and product decides which epic slips rather than letting the team absorb it silently. Then look at where the defects came from using the introduced-by links, because an overrun concentrated in one epic is a different problem from one spread evenly.
How to run a root cause analysis
Answered on How to run a root cause analysis, and rendered here in the same words.
Read the page these answers live on →
How is an RCA different from live monitoring?
Live monitoring is the scheduled watch over a change after it ships: customer impact, support volume, the FAQ and the support macro, and the continue, watch or rollback call. It runs on every release, whether or not anything is wrong. An RCA is triggered by what live monitoring finds, or by an incident that arrives with no warning at all. Live monitoring asks whether this release is behaving. An RCA asks why the system allowed it not to, and it ends in funded tickets rather than a call.
Who should run the session?
Someone who did not build the thing that failed and does not manage the people who did. Their job is the method rather than the investigation: holding the timeline until it is agreed, applying the counterfactual test to every candidate cause, and stopping the room whenever an answer names a person instead of a control. Keep the room to the people who were there plus that facilitator. Once it becomes a stakeholder audience, people start performing rather than remembering, and you lose the detail you came for.
What if the cause sits with a supplier we do not control?
Then you have found the trigger and you still owe the conditions. You cannot action a third party's deploy schedule, but you can action the timeout you did not set, the fallback you did not build, the contract test you did not write, and the alert that would have told you their response had changed shape. Raise the commercial conversation separately, and log the dependency in the RAID log as an accepted risk with a review date, but do not let a supplier's name become the reason no ticket was raised.
Is this supposed to be blameless?
Blameless means the cause is never a person, not that names vanish from the timeline. Write plainly that an engineer ran the deploy at 09:12, because the timeline is worthless without it. What you never write is that the engineer was the cause. If the honest finding is that one person's memory was the only thing standing between a change and production, then the missing control is a gate, and the action is to build it.
316 questions, grouped by subject
Every question answered anywhere on tenhaw.com sits in one of 39 groups. This is one of them.
Still have a question?
A 30-minute discovery call with James Rooney. Bring the question this page did not answer. You'll leave with a rough scope whether you engage us or not.
Most organisations start with a fixed-price Agent-Readiness Audit · £30k–£90k · 6–8 weeks