On this page
Research context
## Question and scope This protocol asks how often completed maintenance work requires correction or repeat effort within a fixed follow-up window, and what the record shows about the reason. The unit is a maintenance ticket or change that was accepted as complete. The study is about the stability of the delivered outcome and the clarity of the handoff, not about individual developer speed or the number of story points completed. Set the observation window before looking at the data. A fourteen-day window may fit a fast-moving web application but miss a monthly batch process. Choose the window based on how quickly the affected behavior would normally be exercised, and apply the same window to every ticket in the sample. Record the cutoff time and the date of the final follow-up check so a later reader can reproduce the count.
## Population and unit Use the completed ticket as the primary unit. A ticket that is reopened keeps the same key and adds a rework event; a new ticket for the same underlying problem is linked to the original rather than counted as an unrelated success. If one ticket produces several follow-up changes, count the rework event once per distinct acceptance failure and retain the linked tickets as evidence. The unit definition should be piloted on a case that was reopened, a case that received a new requirement, and a case that failed only because the deployment environment was wrong. Include tickets completed by the outsourced team and by the client team when the same queue and acceptance standard apply. If the two groups use different definitions of done, report them separately. Record the work type, risk class, reviewer, and whether the ticket touched shared infrastructure or a customer-facing path. These fields help explain a difference without turning the rate into a league table. Exclude a ticket only with a recorded reason, such as duplicate, cancelled before work, or completed outside the study window. Do not remove a difficult case because its follow-up is hard to classify. A high exclusion count is itself a finding about the queue or the record.
## Rework definition Rework exists when the accepted outcome does not hold and the team must change the same behavior again within the follow-up window. Typical events include reopening the original ticket, a linked corrective ticket, a revert, a hotfix, or a follow-up pull request that changes the same acceptance condition. A new feature request, a changed business rule, or a cosmetic preference is not rework unless the original acceptance standard already required the behavior. Classify the reason using a short list: incomplete requirement, implementation defect, test gap, environment or deployment mismatch, data problem, dependency change, or unclear ownership. Add a separate flag for whether the original reviewer could have detected the issue with the evidence available. That flag is not a blame measure; it helps distinguish a review gap from a requirement that changed after approval. Record the time from completion to the rework event. A correction on the same day and a correction three weeks later may have different causes. If the follow-up window extends beyond the available data, mark the ticket as censored rather than assuming it was stable. Censoring is especially important for slow-moving maintenance queues where a defect may not be exercised during the study.
Practical application
## Data collection Join the ticket system, repository, release record, and incident log using a stable ticket key. For each completed ticket, capture the completion time, the acceptance evidence, the reviewer, the linked pull request, the deployment identifier, and any follow-up event inside the window. If the systems use different identifiers, keep an approved crosswalk and record how it was built. Do not rely on title matching to connect a fix to a reopen. Extract the data at one point in time and record the extract date. Queue exports change as tickets are edited, so a later reader needs to know when the snapshot was taken. Preserve the original status and the later status instead of overwriting history. If a ticket was moved between projects or renamed, note the move and keep the original key. Mask customer names and personal data before analysis. Store the evidence reference rather than a copy of sensitive ticket content. A small sample with reliable links is better than a large export that cannot be traced back to the acceptance decision.
## Analysis and reporting Report the number of completed tickets, the number with a rework event, the number censored before the end of the window, and the number excluded. Present the rework count per hundred completed tickets with the window and the denominator. If the team needs a second view, show the median time to rework and the share of events that were detected by a customer rather than by the team. Break the result down by work type and reason only when each group has enough cases to be interpretable. A rate based on three tickets can be a useful case study but not a stable estimate. Show the actual cases behind an unusual result and describe what happened. Compare periods only after checking whether the work mix, acceptance standard, or follow-up window changed. Do not describe a lower rework rate as proof of better quality until the team checks whether the follow-up window was long enough and whether difficult cases were excluded. A queue that closes tickets faster but receives fewer follow-up reports may simply have weaker detection. Pair the rework measure with a second signal, such as reopened defects, customer-reported issues, or the share of tickets with reproducible acceptance evidence.
Operating controls
## Limitations A ticket that is never reopened may still have failed; the customer may have stopped reporting it, moved to another channel, or worked around the problem. The queue is a record of what was captured, not a complete census of product behavior. Rework can also be invisible when a developer fixes the issue in the same pull request before merge, or when a client team member makes a small correction without opening a ticket. Definitions of done vary across teams and over time. A change in the ticket template, the reviewer, or the deployment process can move the rework rate without changing the underlying defect rate. The study should report those changes and avoid attributing the movement to a single cause. If the sample is small, present the case count and avoid percentage claims that imply precision. The cited secure-development and delivery sources describe practices, not a local benchmark. The result is a description of this queue during this window. It should inform a review conversation, not become a performance rating for a supplier or an individual.
## Review and next action Pick one correction that matches the dominant reason: clarify acceptance evidence, add a missing regression check, fix a deployment step, or change the ownership of a recurring dependency. Assign an owner and a start date. Decide in advance which measure should improve and which guardrail should remain stable, such as review turnaround or the share of tickets completed without a follow-up. Re-run the protocol after the change with the same window and definitions. Inspect the cases again rather than relying only on the new rate. If the change did not work, report it and choose a different action. Close the review when the owner accepts the result and the next sample is scheduled.
Sources
Frequently asked questions
What should happen first?
Begin with a bounded ticket, approved access, explicit acceptance evidence, and a named reviewer.
Who approves production changes?
The client's technical owner keeps final merge and release authority.