Feature Creep in a Small Utility
A developer is asked to build a small tool that renames image files to a sequential pattern (img_001, img_002, ...). During development, three new requests arrive: also resize images, also upload them to a cloud folder, and also generate a web gallery page. The developer has one week. The original rename tool is about 90% done. If all requests are accepted, the developer estimates the tool will be roughly 40% complete at the end of the week, with no working deliverable. The manager says: 'Just do everything, we'll sort it out later.'
1. Explain the risk in accepting all three additional requests given the one-week constraint.
Read the worked answer
Accepting all requests spreads the available effort across four features instead of completing one. At 40% overall completion, nothing is usable: the rename tool that was 90% done is no longer finished, and the new features are far from done. The result is the worst outcome - no working deliverable and no clear progress.
The core problem is scope creep under a fixed deadline. With a fixed time budget, adding scope necessarily reduces the completeness of each item. The manager's 'sort it out later' defers the decision but does not create time; it just guarantees that the decision is made under worse conditions, with no functioning product to fall back on.
2. Propose a prioritisation strategy and justify it in terms of delivering value.
Read the worked answer
Prioritise by value and readiness, and sequence so that something useful exists at every point:
- Finish the rename tool first. It is 90% done and delivers its intended value immediately; completing it converts near-done work into a working product.
- Then take the next-most-valuable, lowest-risk request (likely resizing, which is local and self-contained), only if time allows after step 1 is genuinely complete.
- Defer upload and gallery generation to a later iteration - they are larger, involve external dependencies, and are not needed for the core job.
Justification: delivering one finished, working feature beats four half-built ones. This is incremental delivery - each step leaves a usable tool, and the highest-value work is protected from being crowded out by lower-value additions.
3. How should the developer respond to the manager's 'do everything' instruction?
Read the worked answer
Respond with the trade-off made explicit, not with silent compliance or refusal. State plainly: 'With one week, doing all four means none will be finished - you'll get about 40% of each and no working tool. If I finish rename first, you get a usable tool this week and the rest next week.'
This reframes the choice as a decision about outcomes the manager can weigh, rather than a dispute about effort. It also documents the consequence of the 'do everything' path so the risk is owned by the person choosing it. The developer's job is to surface the constraint honestly; the manager's job is to choose the priority - but that choice should be made with the cost visible.