ROI Sprint Planning™
Choose what to build next by impact and effort, adjusted for risk, dependency, urgency and learning.
What it does
ROI Sprint Planning™ - prioritize competing work by Impact / Effort. Use for backlog prioritization, competing initiatives, stakeholder pressure, or when someone asks "what do we do first". Requires at least one QVR or candidate, scores Impact and Effort (1-10), adjusts for risk, dependency, urgency and learning, and returns a ranked table with one-line reasoning and what would change the ranking.
Who it is for
Two or more candidates are competing for the same sprint or the same capacity.
It adapts its questions and its output to 10 roles, delivery and technical.
1. Pick your role
2. Preview
This is the full SKILL.md for Delivery Manager / Delivery Lead: the base instructions plus your role lens.
--- name: roi-sprint-planning description: ROI Sprint Planning™ - prioritize competing work by Impact / Effort. Use for backlog prioritization, competing initiatives, stakeholder pressure, or when someone asks "what do we do first". Requires at least one QVR or candidate, scores Impact and Effort (1-10), adjusts for risk, dependency, urgency and learning, and returns a ranked table with one-line reasoning and what would change the ranking. --- # ROI Sprint Planning™ ROI Sprint Planning™ turns a pile of competing options into a short, defensible queue. It does not fill a sprint with work. It chooses, on purpose, which Quick Value Release (QVR) maximizes value and minimizes friction in the next cycle, and says out loud what is not being done. The unit of planning is the QVR (or a candidate for one), not the individual story. Stories are how a QVR gets built. QVRs are what gets prioritized. The planning hierarchy is: business objective / KPI, then Impact Hypothesis, then QVR candidate (the unit of planning), then stories and technical tasks (the unit of execution). A QVR can contain several stories, never the other way round. A sprint counts as successful only if the QVR is delivered and measured, not merely because the work was completed. In VDS the roles around this decision are: the Impact Owner defines and defends the impact of each QVR; the Technical Value Leader estimates the effort of the whole QVR; the Value Facilitator keeps focus and removes friction; the Strategic Tech Advisor weighs sustainability and systemic risk. Teams without those titles map them to whoever plays the part today. Part of the Value Design System™ (VDS™). It follows Quick Value Release (the `quick-value-release` skill) and precedes the Value Dashboard™. ## Step 1 - Prerequisite check You need at least one QVR, or a candidate that can become one. Ask for the list of competing options. - **QVR cards exist.** Use them. Read signal, scope and effort straight from the cards. - **Only a loose list** (features, epics, requests). Do a quick pass per item: which metric would it move, and by how much? Anything that cannot name a signal is flagged as "not yet a candidate". Offer to slice the top ones with the `quick-value-release` skill. Do not score items that have no signal; scoring them produces false precision. - **No hypothesis anywhere.** Point to the `value-architecture-canvas` skill or offer to build the Impact Hypothesis first. Do not invent options or numbers. Also ask for the decision context: what window is being planned (sprint, month, quarter), who decides, and what constraint is real (people, budget, a date, a dependency). ## Step 2 - Score Impact and Effort (1-10) Score every candidate on the same two scales, and write the reasoning next to each number. Scores are estimates; the goal is comparability, not precision. **Impact (1-10): how much does this move the primary signal, in the value dimension that matters?** Anchor the scale with the user before scoring: what would a 10 look like (the best result any candidate here could plausibly deliver), and what is a 1? Then judge each item against that. For intangible value, score with explicit criteria: reach (how many people), depth (how much changes for each), and duration (how long it lasts). **Effort (1-10): the cost of the whole QVR, not of one task.** Include build, dependencies, waiting time, environments, approvals, instrumentation of the evidence route, and the technical debt it adds or removes. Anchor it the same way: what is a 10 here, what is a 1. **ROI = Impact / Effort.** Ask each score's owner for the assumption behind it. A number with no assumption is an opinion; a number with a stated assumption can be challenged and improved. ## Step 3 - Adjust for risk, dependency, urgency and learning Raw ROI is a starting point. Apply four adjustments, each with a short written reason. This is a heuristic, not a formula: there is no universal weight, and pretending otherwise is false precision. | Adjustment | Question | Typical direction | |---|---|---| | Risk | How likely is it that the QVR will not deliver or not move the signal? | Lowers priority when high | | Dependency | Does it need something outside our control, or does something else need it? | Lowers it when blocked; raises it when it unblocks other QVRs | | Urgency | Is there a real cost to waiting: a date, a window, a regulation, a seasonal peak? | Raises it, only when the cost of delay is real and nameable | | Learning | Would the result invalidate or confirm a critical assumption that many other decisions rest on? | Raises it, sometimes above raw ROI | Mark each adjustment as up, down or neutral and explain it in one phrase. Keep adjustments visible so the ranking can be audited. "Urgent" without a stated cost of delay is pressure, not urgency (see below). Also check shared friction. If two QVRs need the same data feed, environment or approval, doing them together or in sequence may change the order. ## Step 4 - Read the result carefully - **Ties and ranges.** Treat scores as ranges. Two items with a ROI of 2.4 and 2.6 are tied. Small differences are noise at this level of estimation. When items are tied, prefer the one that generates the most learning, or the one that is cheaper to reverse. - **Do not defend the decimals.** If the ranking changes when one score moves by a point, say so: the ranking is fragile and the real work is to learn more, not to argue the number. - **Everything similar?** Then pick the item that teaches the most, and say it is a learning bet. - **Check the result against intuition.** If the ranking feels wrong, one of the scores is wrong, or the intuition is carrying a criterion the scores do not capture. Find which one, and write that criterion down. ## Step 5 - Handle stakeholder pressure with data When a stakeholder pushes for their item, do not argue about importance. Make the trade-off visible: 1. Put their item in the same table, scored with the same scales, with their help. 2. Ask for the signal and the cost of delay: "Which metric moves if we do this first, and what do we lose per week by waiting?" 3. Show what moves down if it moves up: "To put this first, these two wait. Here is what each one was expected to deliver." 4. Offer options, not a refusal: do it now and defer X, slice it into a smaller QVR, or schedule it with a clear trigger. 5. Record the decision and who made it. The decision belongs to the person accountable for the outcome, not to the loudest voice. If the item has a political reason that the numbers do not capture, name it as a criterion and score it. A priority that wins for an unspoken reason will erode trust in the whole method. ## Step 6 - Keep the queue short The queue has three places: - **1 active:** the QVR being built now. - **1 next:** ready to start when the active one is read. - **1 in analysis:** being sliced, baselined or de-risked. Everything else waits or is discarded, and the discards are named. A backlog without discards is a wish list. Revisit the queue when a QVR is read, not on a calendar alone. ## Output format Return a ranked table, one line of reasoning per item, and what would change the ranking. Each item gets a decision: Do, Delay or Discard. ``` ## ROI Sprint Planning: [planning window] - [date] Decision owner: [name/role] Constraint: [capacity, date, dependency] Scale anchors: Impact 10 = [..] Effort 10 = [..] | Rank | QVR / candidate | Strategic objective | Impact (1-10) | Effort (1-10) | ROI | Adjustments (risk / dep / urgency / learning) | Decision | Queue | |------|-----------------|---------------------|---------------|---------------|-----|------------------------------------------------|----------|-------| | 1 | ... | ... | 8 | 3 | 2.7 | risk neutral, unblocks #3, urgency: yes (cost of delay named) | Do | Active | | 2 | ... | | | | | | Do | Next | | 3 | ... | | | | | | Delay | In analysis | | - | ... | | | | | | Delay / Discard | Waiting / Discarded | Reasoning (one line each): 1. ... 2. ... Ties / fragile calls: [which differences are within noise] What would change this ranking: [a score assumption proven wrong, a dependency cleared, a deadline appearing, evidence from the active QVR] Not doing (and why): [named discards] Decision needed: Do we build [QVR] first? ``` Mark the scoring as a heuristic in the output. Do not present a ranking as a calculation that proves the answer. ## Working rules - The user and their stakeholders decide. You structure, question and recommend, with one alternative and its trade-off. - Never invent candidates, metrics or numbers. Scores come from the user and the evidence at hand; label guesses as assumptions. - Aim for comparability, not false precision. Name what you assumed. - Tie each ranked item to its signal. An item with no signal is not ranked, it is sent back to be sliced. - Keep the process light. For two options and ten minutes, a two-row table and a clear reason is enough. ## Role lens The user's role is Delivery Manager / Delivery Lead. # Lens: Delivery Manager / Delivery Lead - ROI Sprint Planning™ ## How the pillar plays out in your day You are not choosing between two stories, you are choosing between teams, engagements and clients competing for the same senior people, environments and executive attention. The ROI question at your level is: given limited capacity across the portfolio, which QVRs deserve it this cycle, and which do not? ROI Sprint Planning™ gives you a portfolio-level language. A team lead can show you a ranked table for their backlog; you stack the tables, compare them on the same scales and move capacity where Impact per unit of Effort is highest. ## Where the ranking happens At your portfolio review or delivery governance meeting, with team leads presenting their top two or three QVR candidates, and in client governance meetings where the client's own priorities enter the table. ## What you own vs what you influence **You own:** allocation of delivery capacity across teams and engagements, escalation and staffing decisions, cross-team dependency management, the governance cadence, outcome reporting to clients or executives. **You influence:** how each team scores (consistency of the scales), which items reach portfolio level, how clients rank requests, which expansion conversations are earned. The ordering inside a team belongs to its Product Owner; the client decides business priority. ## The sharpest questions 1. "Are Impact and Effort anchored the same way across teams, or does a 7 mean different things?" 2. "Which team's top item has the highest ROI, and are we giving it the capacity it needs?" 3. "Where are two teams competing for the same person, environment or approval?" 4. "Which client request is high effort and low impact, and how do we say so without losing the relationship?" 5. "What is the learning value of the lower-ROI item, and does it change the order?" 6. "What would we need to stop to fund this?" 7. "If we re-ran this ranking in four weeks, which scores would we expect to change?" 8. "Which items are on the list only because they are contractually committed, and have we scored them honestly?" ## The artifact you produce, and where it lives A **portfolio ranking sheet**: all active and candidate QVRs across teams, scored with a shared scale, the adjustments, the capacity needed, and the resulting short queue per team. It lives in your governance workspace and is the basis for client conversations about trade-offs. Keep a decision log of capacity moves and why. ## Erosion patterns to watch 1. **Capacity follows the loudest client.** Staffing responds to escalations rather than impact. Fix: show the ranked table to the client with their item scored in it, and discuss trade-offs. 2. **Each team optimizes locally.** Team queues are ordered well, but the portfolio is not. Fix: compare top items across teams monthly and move people on the evidence. 3. **Committed work hides inside the ranking.** Contractual items are skipped in scoring. Fix: score them too, and show what the commitment costs in displaced items. ## Who to involve Team leads and product owners, the client or business owners, peer delivery managers who share people, engineering managers on capacity, and finance for cost-of-delay conversations. ## First 15 minutes Collect each team's top item and ask for Impact and Effort in one line each, with their assumption. Put them on one page. Look for the biggest mismatch in scale between teams, and settle the anchors for the next cycle before you debate any ranking.
3. Get it
Install
Claude.ai
- Download the full skill (.zip).
- In Claude, open Settings, then Capabilities, then Skills.
- Upload the .zip.
- Start a chat and describe your situation. The skill is chosen from its description.
Claude Code
- Download and unzip the full skill.
- Put the folder in
~/.claude/skills/roi-sprint-planning/(all projects) or in.claude/skills/inside your project. - Restart Claude Code and ask for the skill by name, or describe the task.
Cannot install skills?
Use "Copy as instructions" and paste the text into a Claude or ChatGPT chat, or into the instructions of a Project. You can also run the method with the VDS Assistant.
These files are plain Markdown in the SKILL.md format (a name and description, then instructions). Menu names in Claude can change; if you cannot find the option, use the paste route. We have not published test results for specific Claude versions.