Futurespective template

A retrospective run before the work starts: imagine the outcome, then work backwards.

A futurespective is a retrospective pointed forward. Instead of reviewing a sprint that already happened, the team picks a date in the future — the launch, the cutover, the end of the quarter — imagines the work went well, and then describes it in the past tense: what shipped, what made it possible, and what nearly derailed it. The past tense is the whole trick. People are far more specific about a story that already "happened" than about hypothetical risk.

Teams run futurespectives at project kick-offs, before a risky migration, when a new team forms, or at the start of a quarter. The output is not a list of complaints — it is a set of enablers to put in place now and risks to defuse while they are still cheap.

Timebox

45–60 minutes

Team size

4–15 people

Cadence

Project kick-offs, quarter starts, before migrations and launches

The Futurespective board

The headline

It is the target date and this went better than anyone expected. What does the announcement say?

  • The migration finished a week early with zero customer-visible downtime
  • We shipped billing v2 and invoice support tickets halved
  • Three other teams adopted the pipeline without asking us for help
  • We hit the launch date and nobody worked a weekend to get there
  • New engineers shipped to production in their first week
  • The audit passed on the first pass with no findings

What got us there

Looking back from that date, what did we do that made it possible?

  • We froze scope after week two and said no to three late requests
  • We built the rollback path before the first migration batch
  • One person owned the launch checklist end to end
  • We rehearsed on staging with production-sized data
  • We agreed the definition of done before writing tickets
  • We kept a decision log, so no call got relitigated twice

What nearly stopped us

What almost went wrong — and which warning sign did we ignore for too long?

  • The vendor’s rate limits only surfaced in week five of six
  • Two people held all the deploy knowledge and one took leave
  • Requirements arrived as a slide deck nobody owned the details of
  • Staging had drifted from production, so the rehearsal proved nothing
  • We under-estimated data cleanup by an order of magnitude
  • The on-call rota was never updated for the new service

How to run a futurespective

  1. 1

    Set the future date (5 min)

    Pick one specific date — cutover day, launch day, the last day of the quarter — and state what is in scope. Ask everyone to answer in the past tense, as if that date has already passed.

  2. 2

    Write the headline (8 min)

    Silent writing: each person describes the successful outcome as it would be announced. Push for measurable over inspirational — "invoices reconcile in one pass" beats "billing is better".

  3. 3

    Agree on the destination (7 min)

    Read the headlines aloud and group the overlaps. Disagreement here is the most valuable thing the session produces: it means the team was about to build different things.

  4. 4

    Work backwards (10 min)

    Fill "What got us there" and "What nearly stopped us" in silence, still in the past tense. "We rehearsed the migration" surfaces more than "we should probably test it".

  5. 5

    Vote and discuss (10–15 min)

    Vote on the enablers worth committing to and the risks worth defusing. Discuss the top three of each — more than that and none of them get done.

  6. 6

    Turn it into a plan (10 min)

    Each chosen enabler becomes an action item with an owner and a date. Each chosen risk gets a mitigation or a named early-warning signal somebody watches. Review both at the first real retrospective.

Futurespective examples for a project kick-off

Headline

  • The new checkout shipped on 14 March and conversion held steady
  • We decommissioned the legacy service instead of running both
  • Support handled launch week without an escalation

What got us there

  • We shipped behind a flag and ramped traffic 1% at a time
  • Support saw the flows two weeks before launch and rewrote the macros
  • We wrote the runbook during build, not the night before

What nearly stopped us

  • The payment provider sandbox behaved nothing like production
  • Nobody owned the legacy decommission, so it kept slipping
  • Two "small" scope additions arrived in the final week

Futurespective examples for a new team or a new quarter

A team with no shared past cannot run a normal retrospective — there is nothing to look back on. A futurespective gives them the same conversation about how they want to work, before habits calcify.

Headline

  • By the end of Q3 the team ships without me unblocking anything
  • Everyone has been on call and nobody dreads it
  • We said no to two things and the roadmap still landed

What got us there

  • We wrote a team agreement in week one and actually referred to it
  • Every service got a runbook before it got traffic
  • We reviewed action items at the start of every retro

What nearly stopped us

  • Onboarding docs were three months stale and nobody owned them
  • Meetings crept back in until deep work vanished
  • One person quietly became the single point of failure again

Futurespective examples for a migration or platform change

Headline

  • All 40 services moved with one rollback and no data loss
  • The cutover window closed two hours early

What got us there

  • We migrated the noisiest service first, not the easiest
  • We ran a full dress rehearsal, including the rollback
  • We published a daily one-paragraph status so nobody had to ask

What nearly stopped us

  • Dual-write drift went unnoticed for four days
  • The read-only window was longer than support had promised customers
  • Nobody had tested restoring from backup this year

Best for

  • Kick-offs, before the first ticket is written
  • New teams with no shared history to look back on
  • High-risk work: migrations, launches, hard compliance deadlines
  • Teams whose post-mortems keep surfacing risks somebody already suspected

Facilitation tips

Insist on the past tense

The facilitator’s main job is grammar. "We would probably need a rollback plan" is a hedge; "we built the rollback plan in week one" is a commitment somebody can own. Rewrite hedges on the spot.

Use a real date, not "someday"

A vague future produces vague cards. Naming 14 March or "the last day of Q3" forces people to reason about how much actually fits before then — which is often the session’s first uncomfortable discovery.

A risk without an owner is a rumour

Every risk that survives voting leaves the room with either a mitigation and an owner, or a named signal somebody is watching for. Anything else is a list you will reread during the post-mortem.

Run it with the people doing the work

Stakeholders can join for the headline round — alignment on what success means is worth their time. But the enablers and risks come from whoever will actually be holding the pager.

Variations

Remember the Future

The best-known futurespective format: the team imagines a specific future date in detail and describes what happened, hour by hour if needed. Highest fidelity, needs the most time.

Pre-mortem

The inverse, popularised by psychologist Gary Klein: imagine the project failed badly, then explain why. Use it with over-confident rooms — it gives people permission to voice doubts they would otherwise keep quiet.

Sailboat futurespective

Reuse the sailboat metaphor pointed forward: the island is the goal, wind is what will push you there, anchors are what will slow you, rocks are the risks ahead. Friendlier for mixed or non-technical groups.

Hopes and concerns (the 20-minute version)

When there is no room for a full hour, run Hopes and Concerns instead. It gets you the same alignment and risk signal in a third of the time, with less structure.

Frequently asked questions

What is a futurespective?+

A futurespective is a forward-looking retrospective. The team imagines a future date at which the work has gone well, describes that outcome in the past tense, and then works backwards to identify what made it possible and what nearly went wrong. It produces enablers and risk mitigations before the work starts, rather than lessons after it ends.

How is a futurespective different from a retrospective?+

A retrospective reviews work that has already happened and changes how the team works next time. A futurespective is run before or at the start of the work and shapes how it will be done — the format and facilitation are near-identical, only the tense and the timing change.

What is the difference between a futurespective and a pre-mortem?+

A pre-mortem is one kind of futurespective. It imagines only failure — "the project went badly, why?" — while a full futurespective covers the success story and the enablers as well as the risks. Pre-mortems are sharper at surfacing doubts; futurespectives also build shared agreement on what success means.

How long does a futurespective take?+

Plan 45–60 minutes for a team of up to 12: 5 minutes to set the date, 8 minutes writing headlines, 7 minutes agreeing on the destination, 10 minutes working backwards, and 20–25 minutes to vote, discuss, and assign owners.

When should a team run a futurespective?+

At project kick-offs, when a new team forms, before a migration or launch, and at the start of a quarter. Any time the cost of a surprise is high and the team has not yet locked in how it will work is a good moment.

Run Futurespective online in FocusRetro

Start a blank board, name the columns The headline / What got us there / What nearly stopped us, and invite the team with a link — then run the phases with timers, hidden cards, and blind voting. Free plan available at focusretro.com.

Start a board free

No credit card required

Related guides