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
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.
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.