✦ For everyone, free.

Practical knowledge for real and everyday life

Home

Work Process Evidence Review

Work Process Evidence Review evaluates how agile projects manage tasks, ensuring transparency, accountability, and continuous improvement through documented evidence.

Work Process Evidence Review is the practice of systematically examining concrete, factual records of how work actually proceeded during an iteration — task flow data, incidents, cycle times, and similar objective indicators — as a grounding input to a retrospective, ensuring that the team's reflection is anchored in what demonstrably happened rather than relying solely on selective memory or impression. It sits alongside data gathered during retrospective preparation, providing the factual backbone against which participants' subjective observations can be checked and contextualized.


Why Evidence Matters Alongside Memory

Memory Is Selective and Recency-Biased

Human recollection of a multi-week iteration tends to emphasize the most recent, most emotionally charged, or most personally relevant events, while gradually forgetting steady, low-drama patterns that may nonetheless represent significant process issues. Reviewing objective evidence counteracts this bias by surfacing patterns that were present throughout the iteration, not just the ones freshest in participants' minds.

Evidence Provides a Shared, Verifiable Starting Point

When a retrospective begins from a common set of facts about what actually happened, disagreements are more likely to center on interpretation and response rather than on disputing basic facts, which keeps the discussion more efficient and more likely to converge on a genuinely useful improvement.


Types of Evidence Commonly Reviewed

Work Item Flow Data

Records of how individual tasks moved through the team's workflow — when they were started, how long they sat in each stage, and when they were completed — reveal bottlenecks and inconsistencies that may not be obvious from anecdote alone, particularly when a delay was gradual rather than caused by a single memorable incident.

Incident and Blocker Logs

A record of blockers encountered during the iteration, including how long each persisted before resolution, gives the team an objective view of where friction actually occurred, distinct from which blockers happened to be discussed informally at the time.

Commitment Versus Completion

Comparing what the team planned to accomplish against what was actually completed by the end of the iteration provides a factual measure of the gap between intention and outcome, which can prompt useful discussion about whether planning, estimation, or execution is the primary source of any consistent shortfall.

Quality and Rework Indicators

Data on defects found after work was considered complete, or on work that had to be redone, points to process weaknesses in verification or definition of done that might otherwise be attributed informally to bad luck rather than a systemic pattern.


Integrating Evidence Into the Retrospective

Presenting Evidence Without Predetermining Conclusions

Evidence is most useful when presented neutrally, as a set of observations for the team to interpret together, rather than pre-packaged with a conclusion already attached, since premature framing can bias the discussion before participants have had a chance to offer their own reading of the data.

Using Evidence to Prompt, Not Replace, Discussion

The purpose of evidence review is to ground and enrich the conversation, not to substitute for it; numbers alone rarely explain why a pattern occurred, and the qualitative discussion that follows is where the team develops genuine understanding of the underlying cause.

Cross-Checking Evidence Against Participant Recollection

Discrepancies between what the evidence shows and what participants recall are themselves valuable, often revealing either a gap in what the data actually captures or a distortion in memory, and surfacing this mismatch openly tends to produce a more accurate shared understanding than either source alone.


A Sample Evidence Summary Visualization

To Do In Progress Review Blocked Done High Low

A visualization of this kind, showing an unusually tall "Blocked" bar relative to other stages, gives the retrospective a concrete, evidence-based starting point for investigating why items were stalled and what specifically caused the blockage, rather than opening the discussion with an unfocused general question about the iteration.


A Simple Metric for Flow Consistency

Comparing the variability in how long similar work items took against their average duration gives a sense of how predictable the team's workflow was during the iteration.

Flow Variability = Standard Deviation of Cycle Time Average Cycle Time

A high variability value indicates that similar items took inconsistent amounts of time to complete, which is often more revealing of a process issue than the average duration alone, and it can serve as a specific prompt for retrospective discussion.


Common Pitfalls

Overloading the Retrospective With Raw Data

Presenting an excessive volume of unsummarized metrics can overwhelm participants and consume time that should be spent on discussion rather than data comprehension, so evidence should be distilled into a small number of clear, relevant indicators before the session.

Treating Evidence as Infallible

Objective-looking data can still be incomplete, mismeasured, or missing important context, and treating it as beyond question can lead the team to draw incorrect conclusions; evidence should inform discussion, not silence legitimate challenges to its interpretation.

Selectively Presenting Only Favorable Evidence

If evidence is curated to support a predetermined narrative rather than presented comprehensively, the retrospective loses its grounding in genuine fact and risks reinforcing existing biases rather than correcting them.