Delivery Prioritization: Scope, Speed, Quality, and Cost Questions

Direct answer. I would re-plan the remaining work to the reduced capacity instead of asking the team to work harder, keep the committed must-haves, defer by value, and tell stakeholders within a day with a revised plan and a date for confirming it. Trust comes from early, specific communication, not from holding the original promise.

Do the arithmetic first (illustrative team). A person-day is one engineer working one day. 10 engineers, two-week sprints of 10 working days: 100 person-days per sprint. Mid-sprint, 50 remain in this sprint plus 100 in the next, so 150 person-days planned. A 30% drop gives 105, a gap of 45.

Re-plan.

• Reserve about 10 person-days as buffer (illustrative, roughly 10% of the 105, slack for estimate errors and further absences), leaving 95 usable.
• Sort remaining work in MoSCoW style (must / should / could / won't have this time, the four categories of the DSDM method's way to rank scope; here the deferred items become the won't-have-this-time group): must-have 90 (release-blocking, committed), should-have 40, could-have 20 (sum 150).
  • Must-have 90: checkout rework 60, security patch 30.
  • Should-have 40: onboarding emails 5, search filters 25, saved views 10.
  • Could-have 20: dark mode 12, admin tweaks 8.
• The must-haves fit with 5 left, which is exactly the onboarding emails. Deferred: search filters 25 + saved views 10 + dark mode 12 + admin tweaks 8 = 55 person-days.
• Choose deferrals by cost of delay (the value lost for each week an item waits), not size: dark mode and admin tweaks hurt nobody if they wait, so they go first. If filters were what a signed customer was waiting for, they would outrank the smaller items.
• Do not add people now. Brooks's law says adding people to a late project tends to make it later because of ramp-up and communication overhead. Narrow, well-specified work can go to someone already familiar with the code.
• Keep quality gates (the checks a change must pass before release, such as tests and review); cutting tests to recover capacity creates the next incident.

Moving the date is a last lever. If must-haves exceed capacity, say so and offer a date range with the conditions, rather than a quiet slip.

Communication.

• Stakeholders (within 24 hours): what is affected, what is safe, new scope, and when I will confirm.
• Customers: commit only to what is protected; explain deferred items plainly, with the date they return.
• Weekly updates until capacity recovers.

An incident takes 40% of capacity. Same method, but triage first: contain the incident, assign an owner so the 40% is not spread across everyone, then recompute. At 60% of 150, 90 person-days remain: only must-haves fit, no buffer. Plan the recovery over several sprints: finish the incident follow-ups, then bring back deferred items in value order.

What would change my call: if the illness is brief, I hold scope and absorb through a short buffer, and tell stakeholders it is a watch item.

Direct answer

I would first make the discovery precise, then compare three options on cost, risk and debt: refactor now, postpone, or take an incremental middle path. A refactor is restructuring existing code, without changing what the product does, so it is easier and safer to change. Technical debt means shortcuts or outdated structure in the code that make future work slower or riskier. In most cases I lean toward the incremental option: refactor only the part the feature depends on, and schedule the rest explicitly. I would change that if the unplanned work is small (just do it) or if the shortcut would lock in something hard to undo.

Step 1: understand the refactor

Ask engineering what exactly must change, why the feature cannot ship without it, what happens if we work around it, and how sure the estimate is. A workaround is a quick, narrower fix that avoids the restructuring but leaves the underlying problem in place. An incremental approach means doing the smallest slice of restructuring that unblocks the feature.

To find that slice, I ask engineering to list every part of the code the feature will read or change, then split the refactor list into two groups: items the feature cannot work without, and items that are only nice to have. Example (illustrative): the feature needs order statuses restructured, which takes 2 weeks, while the rest of the refactor (reporting and notification code that also uses the old structure) takes the other 2 weeks and can wait.

Step 2: compare options (illustrative weeks)

Assume the feature takes 6 weeks, and the full refactor takes 4. "Debt left" means how much of the shortcut or outdated structure is still in the code afterwards.

The estimate range matters more than the single number: if engineering says the refactor is "4 to 8 weeks," I plan for the high end and ask what drives the uncertainty.

Step 3: decide and why

Incremental, unless the workaround is cheap and short-lived (then postpone with a dated ticket), or the date is immovable and the customer value of 6 weeks outweighs everything (then ship the workaround behind a feature flag, a switch that turns the feature on or off without redeploying, and commit the refactor).

Stakeholder alignment

I tell product: "To deliver this safely, the date moves from 6 to 8 weeks, or we ship a workaround at 6 and pay 4 weeks of cleanup later." I give two choices with consequences. I tell leadership the date change early, with the reason, and whom it affects.

Delivery risk and debt

Break work into slices that each ship, re-estimate after the first slice, and put the deferred refactor on the roadmap with an owner so it is not forgotten.

My first response: do not say yes or no yet

I ask what the demo has to achieve and what the stakeholder wants the audience to see. Example: a sales lead asks for a new "export to PDF" report in next week's customer demo, and the real need is that customers see the reporting story. Often the idea has to be shown, not a working production feature.

Offer instead (in order of preference)

1. A scripted demo path: a clickable prototype or hard-coded flow, clearly labelled as a preview. Roughly 2 days, not 3 weeks.
2. A roadmap slide with a dated commitment.
3. Move the demo, only if the audience's decision depends on the feature working for real.

Is the extra value worth the disruption? (a quick scoring, with illustrative numbers)

I score each option 1 to 5 on how much it changes the audience's decision (value) and how much it risks (broken live demo, work pulled from committed items, rushed QA):

One week remains and the feature needs three, so a real build cannot fit; the choice is only which preview to show. I also ask how much the feature would change the audience's decision, because that sets how much disruption is justified.

Getting agreement from the people affected

A late request touches several teams, so I walk the critical path (the longest chain of dependent steps, which sets the earliest finish) with engineering, QA, product and whoever owns the demo environment. Steps marked (CP) are on it. Every step here waits for the one before it, so all five days are on the critical path and there is no spare time (float): a one-day slip anywhere moves the rehearsal into the demo day, which is why the freeze on day 4 is not negotiable:

When a senior stakeholder wants the real feature released immediately instead

If the team needs time to harden it (fix rough edges and test under real load), I propose partial delivery: release behind a feature flag (a switch that turns the feature on for chosen users only) for internal users or a small percentage of customers. A monitoring plan (what we watch, such as error rates) and a rollback (switching it off or reverting quickly) make that safe. I say it as protecting the stakeholder: "this gets you a first result this week and avoids an incident in front of your customers."

Direct answer

Recompute what you can deliver from the real, lower capacity, keep a small reserve, and protect commitments in order of how much damage breaking them does: signed customer and compliance obligations first, then promises tied to signed or pending revenue, then internal and marketing-timed work. Renegotiate the softest commitments first, and do it early with a concrete alternative, never a bare apology.

1. Re-plan from capacity (illustrative numbers)
An engineer-week is one engineer working one week. Ten engineers, 12 productive weeks per quarter (a 13-week quarter minus holidays, meetings and time off), two quarters: 10 x 12 x 2 = 240 engineer-weeks. A 40% drop leaves 144. Hold back 15% as a reserve for bugs and unplanned work (21.6; 15% is a common starting assumption that I would tune using the team's past unplanned-work share), leaving 122.4 to plan.

Commitments total 216 engineer-weeks (90% of the original 240):

Kept: 30 + 20 + 40 + 12 + 20 = 122, within 122.4. Deferred: 24 + 10 + 36 + 24 = 94, and 122 + 94 = 216.

2. Order of renegotiation

1. Marketing launch feature and dashboards: internal, nothing signed, easiest to move.
2. Onboarding and reliability: phase them and say what part stays.
3. Sales: SSO is kept, but agree which unsigned deals depend on anything deferred.
4. Customers: last, only if protecting them fails; the contractual integration stays.

3. The message to each group

• Marketing: new capacity numbers, which feature moves and to when, and what could still run in the campaign. Sample: "Engineering capacity is down 40%. The launch feature moves from Q1 to Q3; for the campaign you can still use [existing capability]. I will confirm the new date after the week 4 re-plan."
• Sales: what they can promise this half, what they must not promise, and a monthly update. Sample: "SSO is protected for the committed customers. Please do not promise dashboards v2 or the marketing feature to any deal until I confirm."
• Customers: contacted by the account owner, before the date is missed, with the new date and an interim option.
• Executives: the trade-off in one table, with what restores the deferred items.

4. Other situations
The same method applies when the loss is planned or temporary.

• Planned loss: if compliance work consumes 30% for six months, the same method applies from the start: 240 x 0.7 = 168, and 168 x 0.85 = 142.8 plannable (the reserve is again 15% of the capacity left).
• Temporary hit: a 40% drop for four weeks costs 16 engineer-weeks (0.4 x 10 x 4). Here the engineers are back to normal strength for the quarter, so the reserve is 15% of the normal 120 engineer-weeks per quarter (10 x 12), which is 18. Do not compare that with the main plan's 21.6: that figure is 15% of 144 and covers both quarters together (10.8 per quarter at the reduced capacity), so the two are on different bases. 16 fits within the 18-week quarterly reserve, so the reserve can absorb it once. Recovery plan: week 1 stabilize and resume; weeks 2 to 3 return to full pace; week 4 re-baseline (recompute the plan from actual progress and capacity). Do not add contractors mid-crisis; new people slow the team first (Brooks's law: adding people to a late project tends to make it later, from The Mythical Man-Month).

Pitfalls: assuming the drop is temporary without evidence; spreading the cut thinly across everything.

Direct answer

Treat it as a decision about launch risk, not a fight between two teams. I would run one 60-minute facilitated meeting with agreed criteria, ship a compromise that uses only the slack (spare capacity beyond work already committed) the schedule really has, and then change the process so scope and testing are negotiated before the last month, not during it.

Facilitated meeting agenda (60 minutes, five roles: PM facilitates, marketing, engineering, QA, and a design or data voice)

That adds to 60.

Decision criteria

1. Customer or revenue value of each feature, with evidence rather than opinion.
2. Blast radius: how many existing users and flows a defect would touch.
3. Reversibility: can it be switched off after launch? A feature flag (a switch that turns a feature on or off without redeploying) makes a feature reversible.
4. Effort against the real slack in the plan.
5. Date rigidity: is the date tied to an event or contract, or just a preference?

Scoring the options (the 15-minute item, illustrative)

Each feature gets 1 to 5 on criteria 1 to 4, where 5 favours shipping it on launch day (high value, small blast radius, easy to switch off, small effort). Date rigidity (criterion 5) applies to the whole launch, so in this example it is settled first: the campaign date is fixed.

A fits the launch. B is valuable and reversible but its size and blast radius do not fit launch day, so it follows.

Short-term compromise (illustrative numbers)

Four engineers for four weeks is 80 engineer-days. 70 are committed, so slack is 10. Feature A costs 5 days, feature B 10 days, and engineering asked for 5 days of extra testing. Doing everything needs 20 days against 10 of slack, so it does not fit. Ship feature A (5 days) plus a 4-day targeted regression pass on the areas A touches. That is 9 of 10 days. Feature B is built in the two weeks after launch from the next period's capacity and ships behind a flag, so marketing still gets it. The staged rollout (5% of users, then 25%, then everyone) does not replace testing for A; it limits B's blast radius, because a problem shows up for 5% of users first and the flag switches B off. That addresses engineering's regression worry for B without spending launch-week days.

Long-term process change

• Scope freeze at three weeks before launch: a cut-off date after which adding anything requires naming what comes out or moving the date.
• Quality gates agreed at kickoff: pass/fail checks that must be met before launch (for example, the regression suite passes and no critical bug is open), written down and owned by engineering.
• Reserve planned slack (about 10 to 15 percent) for late requests, so the argument has a budget.
• A joint launch-readiness review one week out (a meeting that checks each gate is met) and a retrospective after (a review of what to change next time).

Pitfalls: splitting the difference mechanically (half the features, half the testing) satisfies nobody and ignores risk; letting the loudest function win teaches the other to inflate its asks.