Most retros ask
What do we remember slowing this down? Answered weeks after the fact, by whoever speaks first in the room.
FREE TEMPLATE
Engineering Project Retrospective Template
Two documents and three sheets, including a Delay Attribution sheet built from ticket history and the scope change log rather than what the retro meeting remembers.
Free download · No account needed
Delay Attribution, one row
What caused each day of the overrun, tied to a record, not a memory
Filled in once the ticket export and Scope Change Log both exist.
This pack reconstructs
What does the ticket's status history and the Scope Change Log actually show happened, on the day it happened?
Cause
Blocked on another team, a dated scope addition, or logged time past estimate with nothing else on record, each with its own days attached.
Page one for this query is retrospective templates built around a facilitated meeting: sticky notes on a timeline, a blameless discussion, a list of what went well. The most rigorous of them, a project post-mortem template, argues specific data beats a vague retrospective, citing "we estimated 16 weeks and delivered in 18" as the standard a finding should meet. But naming that two-week gap is where its own template stops. Attributing it to a cause is still a discussion prompt, filled in from what the room remembers weeks later.
This pack reconstructs the gap from the record instead. Estimate versus Actual by workstream quantifies exactly where the schedule slipped. Delay Attribution then traces each portion of that slippage to a cause on file. That means a ticket's status history showing time genuinely blocked on another team, a dated entry in the Scope Change Log, or a ticket whose logged time simply ran past its estimate with nothing blocking it. That last case is what an underestimate looks like once recollection drops out of the count.
At Talbrook Systems, a fictional B2B software company, a customer data export pipeline planned for 12 weeks took 19, a 58 percent overrun spread across four workstreams. The retro meeting's notes blamed a vendor's API access delay as the main reason. The ticket history says otherwise. That block cost 8 of the 35 lost days, the smallest of four traced causes, while three tickets that ran past their estimate with no recorded blocker cost 12, the largest share. Nobody named the second one in the room, because it never became one memorable event.
What's in the pack
01
Estimate versus Actual by Workstream
Planned versus actual duration for every workstream, so the total overrun is a sum of named, measured gaps rather than one end-to-end date slip.
02
Scope Change Log
Every addition to the original plan, dated and sized, so scope creep is a set of entries with a cost attached rather than a shrug in the retro.
03
Delay Attribution
Each day of the overrun traced to a cause on file, a blocked ticket, a scope addition, or logged time that ran past its estimate with nothing else recorded against it.
04
Retrospective Narrative
The story the numbers tell, including what the team named out loud in the meeting and whether the record actually backs that memory up.
05
Improvement Actions
One change per attributed cause that actually moved the schedule, sized to the days it cost rather than to how loud the conversation about it was.
How it works
- 1
Open it in River, or download it
Edit with AI opens the pack as a private Space with the agent ready to reconstruct the delay. Download hands you two Word documents and three CSV sheets, no account needed.
- 2
Send the original plan and the ticket export
The plan's workstreams and planned dates, a ticket export covering the project, and whatever scope changes you can already point to.
- 3
Get the delay traced to its actual cause
River measures where the schedule slipped by workstream, then attributes each day of the gap to a blocked ticket, a scope entry, or logged time past estimate.
- 4
See whether the room's memory matches the record
The Retrospective Narrative sets what the retro meeting said next to what the ticket record shows, so a disagreement between the two is visible rather than assumed away.
Frequently asked questions
Is this template free?
Yes, and the download needs no account, card or email. Edit with AI is the optional half, where River reads your ticket history and scope-change record and builds the delay attribution from it. The rest of the template library works the same way.
What format are the downloaded files?
Two documents as .docx and three sheets as .csv, in one zip. Word, Pages, Google Docs, Excel, Numbers and Sheets open them with nothing to convert. The sheets ship with the Talbrook Systems worked example already filled in, so the workstream gap and the four attributed causes are visible before you replace them with your own project's numbers.
Why not just ask the team what slowed things down?
Ask them too; the Retrospective Narrative is where that goes. But a single memorable incident carries outsized weight against several less dramatic ones. A vendor that blocked one ticket for a week is what the room remembers. Three tickets that each ran a few days over estimate, with nothing dramatic attached to any one of them, usually are not.
What if our tickets don't have clean status-history data?
Attribute what the record actually supports and mark the rest unattributed rather than guessing. A rough Scope Change Log reconstructed from Slack threads and pull-request timestamps still beats a memory-only account, and an honest "unattributed" bucket on the sheet is more useful than a confident cause nothing on file backs up.
Does this feed into our estimation process?
That is the point of keeping it. Three tickets running long with no recorded blocker is exactly the pattern an estimation and capacity forecast should be trained on next time. A delay cause that shows up on a second project belongs in a technical risk register instead of being rediscovered from memory again.
Does this replace a launch readiness review?
No, and it usually follows one. A launch readiness review gates whether a specific launch is safe to ship. This pack looks back at the whole project afterward, whether the schedule held and exactly why when it did not, tied to the record rather than the room's memory of it.
Our project records can't leave our network. Can we still use this?
Yes. A private AI workspace builds the workstream comparison and the delay attribution inside your own tenancy. No ticket content, scope-change note or delivery date crosses a boundary your security team has not already reviewed and approved for planning data like this.