Action Items vs. Decisions: Why Tracking Tasks Loses the Reasoning
An action item is a task: what will be done, by whom, by when — it closes when the work is finished. A decision is a choice: option X over options Y and Z, for reasons — and it stays relevant long after every related task is closed, because it explains why things are the way they are. Teams track action items rigorously in task systems while the decisions behind them go unrecorded, which is why settled questions get re-argued. The fix: capture each significant decision with its options and rationale in a decision log, and let action items reference the decision they execute.
Your task tracker is meticulous and your decisions are folklore. The distinction that fixes it is small enough to fit in one line each:
- An action item is a task — what, who, when. It closes when the work is done, and once closed it is inert history.
- A decision is a choice — X over Y and Z, because. It never "closes": it stays load-bearing for as long as its consequences run.
- Tools and habits capture the first and lose the second — the task outlives the meeting, the reasoning doesn't.
- The fix is one habit: significant decisions get a record with options and rationale (the how-to), and action items reference the decision they execute.
The meeting ends well. Three action items land in the tracker within minutes: "Migrate billing to Vendor A — K., end of sprint." "Deprecate the old endpoint — S., Friday." "Update the pricing page — M., Thursday." Owners, deadlines, done-criteria. Textbook.
Six months later all three tasks are long closed — and a new team lead is looking at Vendor A asking why it was chosen over the obvious alternative. The tracker has the answer to a question nobody is asking: who migrated billing and when. The question being asked — why — was never anyone's action item. It was the decision the action items came from, and it lives nowhere.
This is the task-level version of a boundary this series draws three times: at the document level in minutes vs. the decision log, and as a complete writing practice in how to document decisions. This post is the sharpest cut of the three, because tasks and decisions get conflated in the same breath — usually in the meeting's closing minute: "okay, so the action items are…"
The task got tracked.
The decision got lost.
The failure mode of well-run meetings
Action Item vs. Decision: The Actual Difference
Put the two artifacts side by side and they differ on every property that matters:
What it is
Action item: a unit of work — what will be done, by whom, by when. Decision: a resolved choice — option X over Y and Z, for stated reasons.
When it ends
An action item closes when the work ships, and closed means inert. A decision has no done-state: it remains load-bearing for as long as its consequences run — often years.
What question it answers later
The task answers "was it done?" The decision answers "why is it like this?" — the question every new hire, auditor and post-mortem actually asks.
What losing it costs
A lost task resurfaces on its own — someone notices the work missing. A lost decision fails silently: the choice stays in force while its reasoning evaporates, until someone re-litigates it from scratch.
Why the Decision Is the Durable Asset
Here is the asymmetry that makes this worth a post: the action item is worthless after completion; the decision appreciates. Nobody ever needed "migrate billing — K., end of sprint" again after the migration shipped. But "Vendor A over B and build, because EU hosting eliminated B and build cost two quarters" gets more valuable every month — it onboards the new lead in forty seconds, it sets a precedent the next vendor choice can reference, and at contract renewal it tells you exactly which assumptions to re-check.
Teams have the storage exactly backwards: elaborate systems for the artifact with a shelf life of one sprint, and no system at all for the artifact with a shelf life of years. That inversion isn't carelessness — task trackers exist because tasks have owners who feel the pain of losing them this week. A lost decision hurts someone else, later, who can't trace the pain to its cause. (We tallied that compounding cost separately in the cost of undocumented decisions.) Goals inherit the identical inversion — quarterly targets are tracked meticulously and the reasoning that set them is nowhere, which is the case for treating a Key Result as a decision record.
What a Real Decision Record Captures
The repair is not to bloat action items with context — it is to give the decision its own artifact. The full practice is the seven-field record; the task-level essence is three things an action item structurally cannot hold: the options that lost (so "did we ever consider…?" has an answer), the arguments that decided it (so the reasoning can be judged when circumstances change), and a review date (so the choice gets re-examined on purpose rather than by crisis).
Then link downward: each action item that executes the decision references it. "Migrate billing — K., end of sprint (Decision #47)." One pointer, and the tracker's inert history becomes navigable back to living reasoning — which is also the spine of a usable decision audit trail. SPADE names the same seam in its own letters: D produces the decision, and the action items are what falls out of E afterwards — two artifacts from one ritual, which is exactly the separation this post is arguing for.
Action items execute decisions.
They cannot explain them.
A Decision Log Is Not a Task List
One conflation deserves its own warning, because tools encourage it: putting decisions into the task tracker as special tasks. It feels tidy and it fails structurally — the tracker's whole lifecycle is wrong for decisions. Tasks want to be closed; decisions must not be. Tasks get archived out of sight when done; decisions need to stay findable precisely after everything around them is "done." Tasks are owned by the doer; decisions by the decider. Six months in, a decision filed as a task is a closed ticket in an archived sprint — technically stored, practically gone.
The two systems coexist cleanly the moment each holds its own artifact: the tracker tracks work, the log holds choices, and pointers connect them. (Document-level version of the same separation: minutes vs. the decision log.)
"Our Tickets Already Carry the Context"
The strongest objection: modern tickets are rich — descriptions, comment threads, links. The whole vendor debate is right there in the epic's comments, timestamped. Why maintain a second artifact when the discussion is already attached to the work?
Two structural answers. First, a comment thread is a transcript, not a verdict: it preserves everything ever said, in order, with no marker for which argument actually decided the outcome — reconstructing the rationale from forty comments is archaeology, and the next reader won't do it. Second, the thread is filed under the work, not the choice: when the epic closes and the sprint archives, the discussion sinks with it. The record's job is the opposite — a half-page verdict with the decisive reasoning, filed under the question, findable when the work that carried it is long gone.
The honest concession: for small reversible choices, the ticket thread genuinely is enough — this practice is for decisions you'd hate to re-argue. If reversing it costs a sprint or more, it earns a record; if reversing it costs an afternoon, let the ticket carry it.
The Diagnostic
Open your tracker and find a completed task that executed a significant choice. Now try to answer, from anything written anywhere: what were the alternatives, and why did they lose? If the trail ends at "per discussion" — your decisions are folklore with deadlines.
How Argumentree Captures Decisions — With the Reasoning Attached
The reason decisions go unrecorded is that recording them is a separate step after the discussion — and separate steps get skipped. In Argumentree the discussion itself is the record: the question is explicit, options carry their pro and con arguments in a rated tree, and the decision lands with its decisive reasoning already structured. Nothing to transcribe, nothing to reconstruct.
Action items then do the one job they're good at — executing — while every "why" question routes to a living record. The tracker keeps the sprint; Argumentree keeps the reasons. To capture the next decision instead of just its tasks, start free and record one real choice with its reasoning.
Track the Work. Keep the Why.
Action items and decisions are both real artifacts and both deserve systems — the failure is using one system for both and letting the durable artifact die in the disposable one's lifecycle.
So keep the closing minute of your meetings, with one amendment. After "okay, the action items are…" add the second question: "and what did we just decide, and why?" Five minutes, seven fields, one log entry — and the next new lead gets an answer instead of an archaeology project.
Tasks close. Decisions compound.
Give Decisions Their Own System
Argue it once, structured — and keep the reasoning as long as the decision holds.
Sources & Further Reading
- Nygard, M. (2011). Documenting Architecture Decisions. Cognitect.The record-per-decision practice this post applies at the task boundary — decisions outlive the work that implements them.
- Rogers, P. & Blenko, M. (2006). Who Has the D? Harvard Business Review, January 2006.Decision ownership (RAPID®) — why the decider, not the doer, owns the record.
- Architectural Decision Records — adr.github.ioTemplates and tooling for the decision-record practice.
Frequently Asked Questions
What is the difference between an action item and a decision?
An action item is a task — what will be done, by whom, by when — and it closes when the work is finished. A decision is a resolved choice — one option over the alternatives, for stated reasons — and it stays relevant for as long as its consequences run. The task answers "was it done?"; the decision answers "why is it like this?"
Why shouldn't decisions be tracked in the task tracker?
Because the tracker's lifecycle is wrong for them: tasks are meant to close and archive, while decisions must stay findable long after the related work is done. A decision filed as a ticket becomes a closed item in an archived sprint — stored but practically unfindable. Decisions belong in a decision log, with action items referencing the decision they execute.
Do all decisions need a record?
No — only significant ones. A practical threshold: if reversing the choice would cost a sprint or more, or if you'd hate to re-argue it in six months, it earns a record. Small reversible choices can live in the ticket that implements them.
What should the decision record contain?
At minimum the three things an action item cannot hold: the options that lost, the arguments that decided the outcome, and a review date. The complete seven-field template — question, options, arguments, decision, rationale, owner, review date — is in our how-to-document-decisions guide.
Isn't the ticket comment thread already the decision record?
A comment thread is a transcript, not a verdict: it preserves everything said with no marker for what actually decided the outcome, and it is filed under the work, so it archives away when the ticket closes. A record is the opposite — a short verdict with the decisive reasoning, filed under the question, findable after the work is gone.
How do action items and the decision log connect?
By reference: each action item that executes a decision cites its log entry ("Decision #47"). The tracker keeps the work; the log keeps the why; the pointer keeps them navigable in both directions.
Stop Re-Arguing Settled Questions
Structured deliberation with automatic decision records — the reasoning stays as long as the decision does.
About Argumentree Team
Decision Science
The Argumentree team is building the collaborative decision-making platform Argumentree. Our mission is to transform how organizations make, document, and learn from decisions.
Related Articles
Think the ticket thread is enough?
Bring the argument — structured — to the Argumentree forum.
Join the Discussion