The regression pass gets squeezed into the last afternoon of a sprint, and the usual explanation is that the sprint ran out of time. The board is the better explanation. It has a column for building and a column for done, and the checking between them has no name.
A sprint board names the building and skips the checking
Regression testing is a standing obligation rather than a phase, and continuous integration is the shape that obligation took. A suite that runs per change tells a team which change broke something. A suite that runs before a release tells them only that the last few weeks contained a mistake.
Continuous integration absorbed the automated half of the obligation. The half that stays human did not leave with it. Somebody still walks the flows a change touched, on a real build, in a browser the suite does not cover, looking for the thing no assertion was ever written against. On most teams that pass exists, is understood to be necessary, and appears on no card.
The board is where the omission becomes visible. A ticket is picked up and later marked done, and those two columns are the two verbs the tool believes in. The checking that has to happen between them is real work with a real duration, and the board offers it a border rather than a column.
Work a board cannot name is work nobody estimates
Estimation runs on cards. A pass with no card is not sized during planning, never enters the sprint’s committed work, and is never the reason the burndown flattens, because it was not on the chart to begin with. The retrospective then discusses scope, since scope is what the chart shows.
Assignment follows the same route. A card has an owner and an unnamed obligation has whoever is free, which on the last two days of a sprint means whoever finished first. That is frequently the person who wrote the change, checking their own assumptions against flows they were already thinking about, which is the weakest form of quality assurance that still counts as a pass.
What costs the team is the hour the pass ends up running at. A pass running on the final afternoon can produce only two outcomes, because a finding at that hour arrives after the last point at which anything could have been rescheduled. The team ships with the regression or slips the sprint, and that choice is made under the worst available conditions: tired people, a demo already booked, and a defect nobody has had time to size.
Naming the stage leaves the pass exactly as long as it was and moves it earlier in the sprint, which is the only variable that changes what happens when it finds something.
A regression finding outlives its sprint but not its evidence
A regression found late is usually deferred rather than fixed, and the deferral is counted in sprints. The evidence attached to it is counted in days, and those are not the same clock. Which piece of evidence expires on which schedule is set out in UAT best practices end where the finding starts; what nobody does at planning is the conversion into sprints.
Read it on a two-week cadence, substituting your own if it differs.
| Times the finding is pushed | Its age when somebody reopens it | What is left to be triaged from |
|---|---|---|
| Once | 14 days | Everything it carried on the day it was filed |
| Twice | 28 days | Everything, with two days to spare on the shortest of the windows |
| Three times | 42 days | The ticket and its frozen console and network snapshot. The captured log stream is past its 30 days, and on a project running the default recording window the replay went with it |
| Seven times | 98 days | The ticket and its frozen snapshot. The session itself is past 90 days and has been removed |
Two deferrals is the last one that costs nothing, and a backlog routinely holds a low-priority regression longer than that. The third is where a finding stops being a record of a failure and becomes a description of one.
The rule that follows is a planning rule rather than a testing one. A regression carried across more than two sprints gets re-triaged from a written description and a frozen snapshot, and the session replay an engineer would have scrubbed through is not there to open.
The column is what makes the pass schedulable
A pipeline with a verification stage between working and done turns the pass into a card: a stage, an owner, a size, and a line on the chart. The stage is where a ticket waits for somebody other than its author to confirm the fix against the flows around it, which is the work that was previously happening in the gap.
Two fields carry the rest of the scheduling. Severity and priority are stored and filtered separately on our four-stage board, so a regression that is technically critical and commercially not this week can be recorded as both without either field being edited to make the other true. Teams carrying one combined field learn to distrust it, because the only way to schedule a critical defect for next month is to stop calling it critical, and after that nobody can filter on severity and get an answer back.
A verification stage travels only as far as the tracker can express it, and on six of the seven trackers we push tickets into it has to land on something that board already has: a workflow state, a list, a section, a group, a status somebody defined. The adapter moves an issue between the states it finds and never invents one, so on those six the stage is real only if somebody made a place for it during setup, which is the step that gets skipped when the thing being configured had no name in the planning meeting. GitHub Issues is the exception, and it runs backwards: an issue is open or closed, so there is nothing to find and the adapter mints its own vocabulary instead, creating three prefixed labels in the repository when it opens the issue, writing the current stage onto the still-open issue as one of them, and leaving labels somebody else made untouched. Even Linear, whose states carry a type and therefore nearly map themselves, is offered one state per type, so a default team gets its QA stage pointed at In Progress rather than at In Review and its WIP stage left for an admin to finish. Two-way sync needs an authority sets out all seven state models one at a time; the shorter version for somebody planning a sprint is that the stage they have just named on their board is the one their tracker is least likely to have a place for, and the state map is where they find that out.
