Prioritization and Trade-Off Decisions Questions

Direct answer. Start from the capacity: derive what fits, define the one job the MVP (minimum viable product: the smallest product that tests the core idea) must prove, sort features with MoSCoW, and agree the cut order before work starts. Then explain cuts in terms of the goal, not preferences.

Capacity (illustrative: 2 engineers, 6 weeks). 2 x 6 = 12 person-weeks. Keep a 20% buffer (time held back for surprises): 12 x 0.2 = 2.4, leaving 9.6 person-weeks to plan.

MoSCoW (Must, Should, Could, Won't have this time; an approach from rapid application development, a style of building software in short cycles) with estimates, for a community app where people post and follow each other:

Musts total 8.0, plus the Should 1.5 gives 9.5, within 9.6. Coulds (2.0) are not in the committed plan; they only start if we are ahead. Check the Must share against the DSDM (Dynamic Systems Development Method) guideline. MoSCoW was created by Dai Clegg in 1994 for rapid application development and is used heavily in DSDM, whose published guidance is typically no more than 60% Must Have effort, measured against the planned effort for the timeframe (Won't items excluded), with around 20% Could Have effort as contingency. Planned effort here is 8.0 + 1.5 + 2.0 = 11.5 person-weeks, so Musts are 8.0 / 11.5 = 69.6%, Shoulds 13.0% and Coulds 17.4%. That is above the 60% guideline, so this plan is at the risky end: confidence that every Must lands is lower than DSDM recommends. (Against the whole 12 person-weeks the Musts are 67%, and against the 9.6 plannable weeks 83%, but neither is the basis the guideline uses.) The 2.4-week buffer is my own addition, not part of DSDM's rule, and it does not fix the ratio; the fix is to narrow Musts before the build starts, for example a simpler profile (1.0 instead of 1.5) and a chronological feed (1.5 instead of 2.0), which brings Musts to 7.0 of 10.5 planned (66.7%), closer to the guideline though still above it, and to keep the buffer for the surprises that remain.

What to cut first if it slips. Reverse order of value. Because the Coulds are not in the committed plan, the first cut is simply not starting them (notifications, then analytics beyond one launch event) and spending that time on the buffer. If the slip continues, cut comments next, keeping likes only. Musts are never cut; if even they slip, move the date or the launch audience, not quality of safety features like report and block.

Choosing in/out. I use a PR/FAQ (a press release and customer FAQ written as if launched). Write the headline first, for example: "Neighbours can now sign up, post, follow each other, see a feed and stay safe with report and block." If a feature is not needed to write that headline, it is not a Must; direct messages do not appear in it, so they are a Won't. Another way to cut is to serve one segment first. Suppose the app has moderators (volunteers who review reports), power users (who post daily) and casual users (who mostly read). Pick the segment whose need is sharpest, for example moderators, who need report and block to keep a new community safe, and give the others a clear later path.

Explaining cuts. Show the table and the rule: "This is what the first version must prove. Each cut buys the buffer that protects the date." Give the owner of each Won't a date to revisit.