On this page
Research context
## Question and scope The scope is one defined population of deployment window cases observed from first request through verified close in the CI pipeline. A count without a denominator is not a measurement, especially when the queue changes size during the day. Define age from the first recorded request, not from the first time someone remembered to open the case. State whether the study covers one team, one client, or all cases in the defined service. Use the same note in the case file and the study extract; do not create a second version in a personal document. The question should name the unit, the start event, the stop event, and the decision the result is meant to inform. Exclude a reopened case only when the reopening did not create a new requirement; keep the exclusion count and reason. The definitions should be short enough to use at the queue and precise enough to defend in a review with product owner. State whether the study covers one team, one client, or all cases in the defined service. When a case needs an exception, record the reason, the owner, and the date before continuing the review.
## Population and unit The unit is one deployment window case, from the opening request to the verified close, and linked events stay with that case. Record the queue at the start and end of each observation day so additions and withdrawals are visible. The start event should be the first recorded request, not the first time the team opened the case. Keep a list of requests closed as duplicates and show which case survived. Keep the measurement note short enough to read with the case and specific enough to support the reported access exceptions. Record the opening count by owner and channel, because a single total can hide a queue concentrated in one person. Exclude cases opened outside the window only when the exclusion rule was written before collection. The start event should be the first recorded request, not the first time the team opened the case. Record the extraction date and the queue filter so another reviewer can reproduce the population count. If two reviewers disagree, preserve both classifications until the definition or the evidence is resolved.
## Definitions and measures Test each definition on a routine case, a missing-evidence case, and a case that crossed owners. A blank field, a not-applicable field, and a confirmed negative field should have different codes. If a case is outside the scope rule, record the rule and the date of exclusion rather than removing it silently. If two reviewers disagree, preserve both classifications until the definition is clarified. Link the observation to the exact field in the dependency scanner and to the ticket that supports it. Measure elapsed time from the first recorded request to the verified destination update, and report waiting intervals separately. A blank field, a not-applicable field, and a confirmed negative field should have different codes. Define whether a case that waits for a third party is open, paused, or excluded, and apply that rule to every owner. If two reviewers disagree, preserve both classifications until the definition is clarified. Do not let a summary written later replace the evidence that was available at the first decision.
Practical application
## Data dictionary and evidence Mark missing, unavailable, and confirmed negative values separately; collapsing them hides the difference between no evidence and evidence of absence. Use a controlled list for exception reasons; do not let free text become the analysis category. Keep the original evidence reference next to the coded value so the reviewer can verify the classification. Define who may change a coded value and how the change is logged. If the case moved between owners, include both owner periods in the review note and name the handoff time. If the source is a document, record the page or field; if the source is a system, record the record identifier and extraction time. Record the extraction time separately from the event time so a late entry is visible. Store sensitive evidence in the approved repository and keep only the reference in the analysis file. Do not use a zero or an empty string to represent missing evidence. Keep the review note with the case so the next sampler does not have to reconstruct the decision from memory. Each case needs the source, the observation time, the field supported, the owner, and the reviewer. Keep the identity crosswalk in the approved system and restrict it to the review owner. Store sensitive evidence in the approved repository and keep only the reference in the analysis file. Do not use a zero or an empty string to represent missing evidence. When a value is missing, record the missing state and the reason instead of leaving an empty field in the extract.
## Sampling and collection Stop expanding the sample only when the review question is answered, not when the result starts to look favorable. Collect the exception reason and the action taken before the close so the analysis can separate detection from resolution. A sample of recent closures can miss the oldest unresolved work, which is often the most informative. Use a random start and a fixed interval when the frame is ordered, and record both. At Outsourced Programmers, the deployment window review should end with a dated note and a named owner for the next check. Use consecutive deployment window cases where possible, then stratify by owner, channel, and risk class. Use the same collection form for every case and keep the original record linked to the extracted fields. Keep the sample selection reproducible by recording the export date, filter, and random seed or start rule. Use a random start and a fixed interval when the frame is ordered, and record both. If the evidence is sensitive, record the approved reference and access path rather than copying the content. Include adverse cases: a missing rollback plan, a conflicting source, an unavailable engineering manager, and a tight deadline. Collect the case from the CI pipeline, the rollback plan, and the approval record, and stop at the verified close. Include reopened, unresolved, and exception cases in the sample frame. Do not let the reviewer choose the sample after seeing the results. The note should distinguish what was observed, what was inferred, and what still needs an owner decision.
## Analysis and reporting Keep case-level detail available for review, because a summary chart without records cannot support a decision. The analysis should end with the decision the evidence can support and the decision it cannot support. When two groups differ, check whether the difference survives after adjusting for case mix and evidence standard. Use a case-level table to explain an outlier before treating it as a process signal. Record this decision in the study log with the case key, the review date, and the person who approved the classification. For deployment window, report the age distribution and the share of cases waiting on a named decision rather than a single average. Keep descriptive findings separate from causal claims. Use a simple before-and-after comparison only when the definitions and observation window are the same. Use a case-level table to explain an outlier before treating it as a process signal. Keep the evidence reference beside the coded value so a reviewer can test the same case without rebuilding the queue.
Operating controls
## Limitations The method also cannot observe work that never entered the queue, which may be the most important missing population. The study cannot determine whether a professional judgment was correct, only whether the record supports it. If the reviewer also performed the work, note the independence limitation and use a second reviewer for a subsample. State that the result describes the observed sample, not the whole industry or every team in the service. If the source changes after the observation, preserve the earlier value and add a dated note instead of replacing it. Report what remains unknown and what evidence would be needed to answer the next question. Selection bias remains when the team chooses cases that are easy to open or owners who are likely to cooperate. Keep the limitations with the result so a later reader does not turn a local observation into a general claim. Keep the limitations with the result so a local observation is not turned into a general claim. At Outsourced Programmers, the reviewer should be able to explain this step to product owner from the case record alone.
## Review and next action Record the decision and the next check so the study does not end as an archive. A quality review should end with a testable next step, not a general instruction to improve. Link the action to the specific deployment window cases that motivated it. Schedule the next review before the action begins, not after the result arrives. Use the same note in the case file and the study extract; do not create a second version in a personal document. Repeat the protocol after the change with the same definitions, window, and exclusions. If the action changes stale dependency, record the approval from developer before implementation. Keep the old process note until the new process has been tested; do not erase the baseline. Schedule the next review before the action begins, not after the result arrives. When a case needs an exception, record the reason, the owner, and the date before continuing the review.
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.