Bugs and root cause, answered in full.

No. If nobody approved the behaviour being asked for, nothing is defective, the product is doing what was agreed. That is new scope, either 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.

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.

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.

Raise it at the next monthly health check and treat it as a forecast that has broken, not a cap you have breached. Tenhaw reports its own months on those terms, and a month that moves no number the client agreed is written up as a failed month. 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.

One a stranger can act on without finding you. It reproduces on someone else's machine, with the environment, build version, account type, data state and exact input written down. It states expected against actual in two sentences, linking the acceptance criterion or approved journey the live behaviour contradicts, which is what stops triage becoming an argument about whether anyone agreed the behaviour. Severity is set against a published rubric, and anything serious carries a weekly cost in currency. The title names the area, what breaks, for whom and under what condition, so "Checkout: card payments over £500 fail for guest users" beats "payments broken". Keep your theory of the cause in the body, labelled as a theory.

Compare two numbers you can write down, the exposure per day in currency and the hours to a fix you would actually trust. Roll back when the daily exposure exceeds what the change earns per day and the trusted fix is more than a day out, or when you cannot yet bound the blast radius. The call is made explicitly by a named person, on the record, not by drift. On Tenhaw engagements that person is James Rooney, who leads every engagement personally and stays the named escalation route throughout. Record the decision in the ticket with both numbers and the reasoning, including a decision not to roll back, because the root cause analysis will ask for it.

Say so in the first line rather than leaving it implied, then list what you tried, how many users hit it each day, and where you stopped. Attach whatever evidence exists: a trace ID, the log lines either side of the failure, a screen recording. Then give it a decision date fourteen days out with three ways to resolve: reproduce it, ship instrumentation that will catch it next time, or close it with the reasoning written down. The failure mode to avoid is the unreproducible bug that ages for a quarter because nobody can prove it has gone, sitting in the backlog radiating uncertainty.

Multiply the affected users per week by the value lost per affected user, using the same conversion and basket numbers the parent work was priced with, so both sides of the ledger match. A checkout defect hitting 30 guest payments a day at an average £610 basket, where roughly half recover by retrying, costs about £9k a day. A weekly figure in currency does two jobs. It makes the bug rankable against feature work in planning, and it gives the rollback decision a number to weigh against the hours to a trusted fix. Without it, priority gets set by whoever is most annoyed. Tenhaw reports its own engagements as a measured movement, with delivery lead times at Globelynx falling 60% within six months.

No. Fix by severity and by value. A defect that blocks a key journey with no workaround, or carries revenue, safety or regulatory exposure, interrupts the sprint immediately. A degraded journey with a workaround gets scheduled inside the quarter. Everything else, cosmetic defects and edge cases with negligible reach, competes on value with the rest of the backlog, and some of it should be closed unfixed with a note saying so. Closing a low-value bug deliberately, with the reasoning recorded, is healthier than letting it age in the backlog pretending it will ever be scheduled.

Write the regression test before the fix and watch it fail on the affected build. Tenhaw closes defects on that failing-then-passing test, against an open-source standard of 72 rules with RFC 2119 severities. A fix with no test that failed beforehand is a claim, and it is why the same defect returns two releases later. Name the test and the failing build so the next person can rerun it, and close only when the behaviour is demonstrated in the environment where it was reported, not staging. When a model wrote it, correct the requirement first, the user journey or test requirement on the ticket, then have the model implement against it; patching the symptom leaves the requirement wrong, and the next rebuild reintroduces the defect.

About ninety minutes, covering both the writing and the triage. That pass classifies it, reproduces it three times, states expected against actual with the approved source linked, sets a severity and a weekly cost, links it to the quarter's bug budget and to the release that introduced it, and records the continue, watch or roll back call. Against dropping a message into a channel that sounds heavy, and it is meant to. The time comes back twice. Nobody re-argues at triage whether the behaviour was ever agreed, and the tickets never bounce back to you for the detail you left out.

Three, and record the hit rate rather than just the fact that it happened. Intermittency changes both the fix and the test that has to prove it, so three of three and one of five are different defects, and an unstated hit rate hides the hardest part of the work. Note the timestamp of an occurrence you watched happen, and attach a request or trace ID, the log lines either side of the failure, and a short screen recording. Then have someone other than the reporter follow the steps successfully before the ticket moves, which is the only real test of whether they were written for a stranger.

When no user can see it and it is painful only to engineers. Tenhaw made that split pay at Greggs, where throughput data proved that paying down tech debt made delivery faster. A defect users experience goes under the quarter's Bug Budget epic, and one that only slows the team down goes under the Tech Debt epic. Keeping the line clean matters because the bug budget is meant to describe what customers actually met in production, so filing debt against it makes the burn rate say something it does not mean, and filing a customer-visible defect as debt hides it from the quality signal entirely. Decide before you write a word, because everything downstream trusts the classification.

Keep an "introduced by" field on every bug, traced from the release that first shipped the broken behaviour, and leave it empty rather than guessing at it. It is the link most teams skip, and it is what turns the bug budget from a bucket into three numbers at quarter close: burn against forecast, defects per epic, and the severity mix quarter on quarter. Without it you have a count of bugs, which measures how busy the team was rather than where quality is leaking. The quarter close report reads that field, so a bug raised without it goes missing exactly when the pattern matters most.

Four conditions, rather than one person's opinion. Tenhaw holds the same four inside client repositories, where the code and documentation are the client's from day one. The named regression test passes, having failed first on the affected build. A human has reviewed the change. Product has approved it. And the behaviour has been demonstrated in the environment where the defect was reported, not only in staging, because staging is not where the report came from. Anything set as S1 also has its root cause analysis booked before the bug closes, and that session investigates the system that let the defect through rather than the person who wrote the line. A model reporting that it has fixed something is not evidence that it has.

Make the classification a test anyone can apply, and apply it at triage rather than at quarter close. Tenhaw publishes that test in full and free to adopt, so a delivery team can be held to a public document rather than a private convention. A bug has to cite the acceptance criterion, journey or test requirement that the live behaviour contradicts, so moving one to a story is a claim that no such citation exists, which is checkable, rather than a quiet edit that makes a number look better. It matters because relabelling happens under pressure near the end of a quarter, and it leaves the burn rate worthless. The number stops describing quality and starts describing how motivated the team was to protect it.

The user journeys and test requirements written on the outcome ticket. An AI-native team writes no stories and no acceptance criteria, so those are the approved source, and a bug is live behaviour that contradicts one of them. Cite it by link on the expected line exactly as you would an acceptance criterion, because the citation is what stops triage becoming an argument about whether anyone ever agreed the behaviour. Where the ticket is silent on the behaviour being demanded, you are not looking at a defect at all, you are looking at scope, and it belongs in the ticket as a new requirement.

Yes. Bugs go through refinement and sizing like everything else, and through the same phases: todo, in progress, in review, done. The reason is capacity. Unsized bug work still consumes the team's week, it just consumes it somewhere the plan cannot see, and a budget tracked in ticket counts rather than in sized work tells you how busy people were rather than how much of the quarter has gone. Sizing also puts a defect and a feature in the same units, which makes the choice between them a planning decision instead of an improvisation. Past half the budget before half the quarter, raise it at the next health check.