Key Takeaways
- An assumption log is the A in a RAID register: the conditions a plan was built on, written down at planning so somebody can validate them later.
- The log and the confidence vote are the same agreement seen from two angles. The vote is expert engineering judgment about a specific set of assumptions, and it was accurate about the day it was taken.
- Assumptions rarely fail loudly. They expire quietly, and the register still reads “Confirmed” because nobody has opened it since the planning event.
- Each of the three things that erode a committed release date is an expired assumption with a name: scope, dependencies, capacity.
- Release Management, Roadmaps, Portfolio PPM & Timeline re-forecasts the committed date at 50/85/95% confidence from live Jira data, so an expired assumption surfaces as days against the date instead of a stale row in a document.
Week six of a ten-week increment. A stakeholder asks a fair question about the date, and somebody opens the assumption log for the first time since planning.
Every row still reads “Confirmed.” Every last validated cell still shows the morning of the planning event. Nothing in the document is wrong, exactly. It just stopped being true about a month ago, and the document has no way of knowing that.
What the assumption log is actually for
An assumption log is the register of conditions a plan rests on: the platform team will have the auth service in staging by week four, the two contractors start on the first, the compliance review is a formality, nothing else lands in this Fix Version. In RAID practice it is the A, sitting alongside risks, issues and dependencies. In PMBOK-style project management it is a document maintained next to the risk register, with an owner and a validation state per entry.
It is a genuinely good practice, and it is the least-read artefact most delivery organisations produce. The R and the D at least get raised in status meetings — a RAID log’s real problem is its refresh rate, not its structure. The A rarely gets raised at all, because an assumption that is still holding produces no news.
The vote and the log are the same agreement
When a room raises a fist of five at the end of PI planning, it is not voting on a date in the abstract. It is voting on a date given a set of assumptions — this scope, this team, this sequence, this calendar. The confidence vote is the number. The assumption log is the sentence the number is attached to.
That vote is expert engineering judgment, and it is usually right about the day it was taken. People who have shipped this system before, looking at work they have sized, saying how confident they are. There is no better instrument for that question, and no amount of arithmetic replaces it.
A confidence vote is a snapshot. So is the log. Both were accurate on planning day, and neither has a mechanism for staying accurate afterwards.
Assumptions don’t fail. They expire.
This is why the log stays green while the date moves. Assumptions almost never break in a way that generates an event. They lapse. And the three things that erode a release date are, read a different way, three families of expired assumption.
Scope assumptions. “Nothing else lands in this release.” Then a customer escalation is accepted in week three because it is small, and a Definition of Done that was looser than anyone admitted returns three stories as rework. No single decision contradicts the log. The Fix Version is simply bigger than the one that was voted on.
Dependency assumptions. “The auth service is ready by week four.” The platform team never says no. They reprioritise, the date drifts a fortnight, and the change is communicated in their standup rather than yours. The assumption expires in someone else’s backlog, which is the hardest place to watch.
Capacity assumptions. “This team, at this rate.” Then a senior engineer takes the parental leave everyone knew about, one contractor’s start slips by three weeks, and the on-call rotation absorbs more of the week than the throughput history reflects. The roster in the log and the roster clearing work have quietly diverged.
“Confirmed” is a timestamp, not a status
The structural flaw is not that teams keep bad logs. It is that a written register records a validation state as of the last edit, and there is no natural moment that forces the next edit. Between edits, the document and the project can disagree indefinitely without anything in the document looking suspicious.
Which is how the conversation ends up in week nine instead of week three, when the only remaining options are bad ones. The value of catching an expired assumption early is not that it saves the date — often it does not. It is that renegotiating a release date before it slips is a planning decision, and doing it after is an incident.
What it looks like in Jira
This is the gap Release Management, Roadmaps, Portfolio PPM & Timeline is built to close. It does not keep your assumption log, and it does not re-run the confidence vote with better math. The team still owns the assumptions: which throughput window to trust, whose capacity is genuinely in, what is really in scope. The app does the arithmetic at Monte Carlo scale and keeps it current.
The mechanism is that it never stores the assumption in the first place. Scope is whatever is in the Fix Version right now, including what arrived last Tuesday and what came back out of Done. Capacity is observed throughput over a window you choose, against a calendar that knows about the leave. Sequence is the blocking links as they stand today, including the one added after the commitment. Each of those is an assumption the room made, re-read every time the forecast runs.
What you see is a committed date carried with its confidence — March 12 at 85%, say — and a gap in days between that and the date the room agreed to. When an assumption expires, the gap widens before anyone re-validates a row. Three days in week three is a scope conversation. Eleven days in week nine is an apology.
Keep the log. Give it a pulse. See the gap on your next Fix Version, free for 30 days. It Runs on Atlassian, so your Jira data never leaves Atlassian.
Frequently asked questions
What is an assumption log in project management?
An assumption log is a register of the conditions a plan depends on but cannot control — staffing, external delivery dates, scope boundaries, approvals — recorded at planning so each one can be validated as the work progresses. It is the A in a RAID register (risks, assumptions, issues, dependencies), and in PMBOK-style practice it is a project document maintained alongside the risk register, with an owner and a validation state for every entry. Its purpose is to make implicit conditions explicit, so that when one changes, the plan built on it can be revisited deliberately rather than discovered late.
How do you stop planning assumptions from going stale?
Attach each assumption to something that changes on its own rather than to a review meeting. In Jira, the scope assumption is the issue set in the Fix Version, the capacity assumption is observed throughput against the team calendar, and the sequence assumption is the set of blocking links — all three are live data. Release Management, Roadmaps & Portfolio re-forecasts the committed date from exactly those inputs and expresses the result at 50/85/95% confidence, so a lapsed assumption appears as a widening gap in days. Which inputs map to which assumption family is documented in how assumption changes show up in the forecast.
1 Comment
Leave your reply.