Commitment Expiry Dates: Keeping Team Promises From Outliving Their Relevance

Workboard Pro editorial ·

A field notebook containing handwritten notes by botanist Sherwin Carlquist during a field expeditions to Fiji, Japan, California, Florida, Sweden and Denmark between 1978 - 1982. The notebook front and back cover are made of mottled, blue-
Illustrative image. Carlquist, Sherwin John, 1930-2021 · CC BY 4.0 · Cropped and resized. Image source

Most teams track what they promised. Far fewer track whether those promises still matter. A commitment made three weeks ago during a planning call may have been overtaken by a new customer request, a changed launch date, or a teammate who quietly moved on to other work. The promise sits on the board looking active while its original reason has faded. This article describes a different angle on team accountability: giving each commitment an expiry date, so the team is forced to decide, on a schedule, whether each promise should be kept, renewed, reassigned, or retired. The approach does not require monitoring anyone's activity. It relies on a simple question the team asks about its own commitments at predictable moments.

Why commitments go stale without anyone noticing

A commitment usually begins as a sentence in a meeting: someone will draft the onboarding email, or someone will check with legal about the terms. The sentence is clear when it is spoken. Over the following days, the context shifts. The launch slips, the audience changes, or the person who made the promise becomes responsible for something else. Nobody decides to abandon the commitment. It simply stops being revisited.

The problem is not usually bad intent. It is that commitments have no natural end point. A task has a status, but a promise has no built-in moment where someone must ask whether it still deserves to exist. Without that moment, old promises accumulate, and the board becomes a record of what was once agreed rather than a picture of what the team is actually doing. Teams then feel busy and behind at the same time, because part of their list is dead weight they have not formally cleared.

Setting an expiry date that reflects the commitment's purpose

An expiry date is not a deadline for completing the work. A deadline says when the work should be done. An expiry date says when the team should re-examine whether the commitment still makes sense. For a commitment tied to a launch, the expiry might be the launch date itself, because the promise only matters if the launch happens. For an ongoing commitment, such as weekly reporting to a stakeholder, the expiry might be a monthly review point where the team confirms the cadence still serves the stakeholder.

When setting the date, ask the person making the commitment what would make it no longer worth doing. Their answer usually reveals the natural boundary. If they cannot name one, the commitment is probably too vague to track, and the first task is to restate it with a specific outcome. A useful format is: owner, action, outcome, and the date by which the team will reconsider it. Keeping those four parts visible on the card makes it much harder for the commitment to drift quietly.

A monthly retirement review

The most practical way to use expiry dates is a short recurring session, perhaps once a month or at the end of each sprint. Gather the people who own active commitments and walk through only the items whose expiry dates have arrived or passed. For each one, the group chooses one of four outcomes. The commitment can be kept as it is, with a new expiry date. It can be renewed with a changed scope or a different owner. It can be handed to someone with more capacity. Or it can be retired, meaning the team agrees the promise no longer applies and removes it from the active board.

Retirement deserves special emphasis because teams rarely practice it. Many teams treat any removed commitment as a failure to be hidden. In a healthy rhythm, retiring a commitment on purpose is a sign that the team is reading its own situation accurately. Record the decision and the reason in a short note on the card, so the history explains why the work stopped rather than leaving a silent gap.

A checklist for the first expiry review

If you are introducing expiry dates for the first time, start small rather than tagging every card. Pick the commitments that have been open the longest and the ones tied to a near-term launch. Ask the owner of each one to confirm the four parts: the action, the intended outcome, the expiry date, and what would make the commitment obsolete. Where an owner cannot answer, mark the card as needing a restatement before anything else happens.

Then run the monthly review as described above, and compare the results to your previous habit. Several questions will show whether the practice is working. Are fewer cards sitting open for months without a visible decision? Do owners raise scope concerns earlier, before a deadline forces the issue? Does the team feel less guilt when a commitment is retired, because the retirement is now a normal outcome? If the answers are mostly yes, expiry dates are doing their job. If the review turns into a status meeting where nothing gets decided, shorten the list and focus harder on the four outcomes.

The broader point is that accountability comes from making decisions visible and revisitable, not from watching people. A commitment with an expiry date gives everyone a shared, neutral moment to ask whether a promise still holds, and that question is far more useful than asking who is falling behind.