roadmap-update

name	roadmap-update
description	Update, create, or reprioritize the team's roadmap. Use when adding a new initiative and deciding what moves to make room, shifting priorities after new information comes in, moving timelines due to a dependency slip, or building a Now/Next/Later view from Jira epics.
allowed-tools	Read, WebFetch, Bash

Roadmap Update

Update, create, or reprioritize a roadmap built from Jira epics/initiatives — one level above individual sprints.

Step 1 — Understand current state

If Jira/Atlassian is connected: pull current epics/initiatives with status, assignee (or owning sub-team), and target timeframe. Identify items overdue, at risk, or recently completed, and flag any without a clear owner or date.

If Jira isn't connected or the roadmap isn't tracked as epics: ask the user to describe or paste the current roadmap.

Step 2 — Determine the operation

Ask what the user wants to do:

• Add item — gather name, description, priority, rough effort, target timeframe, owner, dependencies. Suggest where it fits given current priorities and capacity.
• Update status — not started / in progress / at risk / blocked / completed / cut. For at-risk or blocked, ask for the blocker and mitigation.
• Reprioritize — ask what changed (new info, strategy shift, resourcing, customer feedback). Apply a framework from below if useful. Show before/after.
• Move timeline — ask why, identify downstream impact on dependent items, flag anything moving past a hard deadline.
• Create from scratch — ask timeframe (quarter/half/year) and format (Now/Next/Later is the default and usually the right call for a 5–10 person team).

Step 3 — Generate the roadmap view

Now / Next / Later (default format):

• Now — current sprint's committed epics. High confidence in scope and timeline.
• Next — next 1–3 months. Scoped and prioritized, not yet started.
• Later — 3–6+ months out. Directional; scope and timing still flexible.

For each item: name, one-line description, status (on track / at risk / blocked / completed / not started), target timeframe, owner, key dependencies.

Follow with:

• Risks and dependencies — blocked/at-risk items with detail; cross-team dependencies; items approaching hard deadlines
• Changes this update — items added/removed/reprioritized, timeline shifts, status changes (if this is an update to an existing roadmap)

Step 4 — Follow up

Offer to: draft communication about a change, or update the corresponding Jira epics' status/dates if the user approves specific changes.

Prioritization frameworks (use when reprioritizing)

• RICE — (Reach × Impact × Confidence) / Effort. Good for a quantitative pass over a large backlog.
• MoSCoW — Must / Should / Could / Won't have. Good for scoping a quarter and forcing tradeoff conversations.
• ICE — Impact × Confidence × Ease (1–10 each). Faster than RICE, good when data is thin.
• Value vs. effort matrix — quick wins (high value, low effort) first; avoid low-value/high-effort "money pits."

Capacity guidance for a 5–10 person team

A reasonable default allocation: 70% planned feature work, 20% technical health (debt, reliability, DX), 10% unplanned buffer. If roadmap commitments exceed capacity, something has to move — don't solve it by assuming people can do more.

Approval gates

• Never update Jira epic status, dates, or priority without the user approving the specific change. Show current → proposed and wait.
• When adding something to Now or Next, ask what comes off. Roadmaps are zero-sum against capacity — say so if the user doesn't raise it themselves.

Tips

• A roadmap is a communication tool, not a task list — keep it at the level of themes and outcomes.
• Dependencies are the biggest risk to any roadmap. Surface them explicitly, don't bury them.
• Batch roadmap changes at a natural cadence (e.g. monthly) rather than reshuffling for every new data point — frequent churn often signals unclear strategy more than good responsiveness.