Contracts and incentives

An incentive contract pays a base price for the release the plan guarantees and rising premiums for the releases it does not, so that buyer and supplier share the risk of a partial delivery [1], [2].

1. Who carries the risk

A Buffered MoSCoW plan is honest: it guarantees only the Musts. The risk of delivering less than everything does not go away, so the only choice is who carries it. Under a fixed price the supplier carries it and charges for it; under time-and-materials the buyer does. Miranda’s contract splits it, so that incentives “prevent the developer from charging a premium price to protect itself from not delivering all features” while the buyer is assured of its best effort [2]. The contract must therefore treat “an agreed partial delivery” as “an acceptable, although not preferred, outcome” [1].

Promising everything only hides the risk: when every requirement is a Must, “typically time (the end date) will slip” [3].

2. Pricing a release by its odds

Example. A publishing house buys Quill, a fictional word processor, as a 4,000-hour time box at $100 an hour: a cost of $400K. The figures are Miranda’s lecture example [4]. The Must release is 2,000 hours and certain; the Should release, 1,000 hours, has about even odds; the Could release, 1,000 hours, about one in four: the method’s double-and-quadruple rule of thumb.

A traditional fixed price of $520K is a 30% markup on cost, not a 30% margin. The incentive version pays on delivery:

The project delivers The client pays Markup on cost Chance of this outcome
Must only $400K 0% 50%
Must + Should $500K 25% 25%
Must + Should + Could $550K 37.5% 25%

At these odds the expected price is about $462.5K, an expected markup of about 16%, against $520K fixed. The gap is the price of the delivery risk. So the supplier sets the base and premiums on the expected price, not the best case: it raises them, or knowingly accepts less money for a lower-risk deal. Framing the same payments as $550K less deductions changes nothing.

3. Team rewards

Miranda applies the same logic inside the team: “No reward will be associated with delivering the ‘must have’ release since the team members are simply doing their jobs” [1]. Rewards attach to the Should and Could releases and are sized by expected value. A large reward with a small chance backfires, because “the team members might perceive this reward as a lottery they are unlikely to win”; a $5,000 reward on a release with about even odds is worth $2,375 [5]. The lecture adds: tie bonuses to release completion, not overtime, and use non-monetary rewards such as training and time off [4]. Motivation itself is on Motivation.

4. Why the buffer needs an incentive

Two behaviours spend buffers, and both are defined on Critical chain. Work expands “so as to fill the time available for its completion” [6], and it starts when the deadline comes into view. Given the same one-hour task, students finished at 4.3 days with a one-week deadline and 9.1 days with a two-week one [7]. And nobody hands time back when an early finish earns no reward and only brings more work [8].

Linking these to the contract is this page’s synthesis, not Miranda’s. The time a Must does not use belongs to the next feature the customer wanted, and a reward for the Should and Could releases gives the team a reason to hand it on.

5. When to use it, and when not

Use it when the buyer can accept a partial delivery and the plan states its odds. If the buyer needs everything, there is nothing to attach a premium to. The pitfall is the odds: the expected price is only as good as the likelihoods behind it.

How solid is this?

  • Where it comes from. Miranda’s contract and reward rules are argument, with no data. The pricing example is lecture material; the markup and expected price are recomputed from its inputs.
  • What is contested. Parkinson’s line is the opening of a 1955 satire, and the student syndrome is a term from Goldratt’s novel Critical Chain. Buehler’s participants were psychology undergraduates. Raz and colleagues note that the padding and Parkinson assumptions behind buffer methods lack “any supporting scientific evidence” [9].

Acknowledgments

This page adapts material from lectures by Eduardo Miranda [4] on software project management.

References

  1. E. Miranda,
    “Time boxing planning: buffered moscow rules,” ACM SIGSOFT Software Engineering Notes, vol. 36, no. 6, pp. 1–5, Nov. 2011, doi: 10.1145/2047414.2047428.
  2. E. Miranda,
    “Moscow Rules: A Quantitative Exposé,” in Agile Processes in Software Engineering and Extreme Programming (XP 2022), in Lecture Notes in Business Information Processing. Springer, 2022, pp. 19–34. doi: 10.1007/978-3-031-08169-9_2.
  3. DSDM Consortium,
    The DSDM Agile Project Framework. Dynamic Systems Development Method Limited, 2014. [Online]. Available: https://www.agilebusiness.org/wp-content/uploads/2026/05/DSDM-Agile-Project-Framework-Handbook.pdf
  4. E. Miranda,
    “Managing Software Development.” 2014.
  5. E. Miranda,
    “Planning and executing time-bound projects,” Computer, vol. 35, no. 3, pp. 73–79, Mar. 2002, doi: 10.1109/2.989933.
  6. C. N. Parkinson,
    “Parkinson’s Law,” The Economist, Nov. 1955, [Online]. Available: https://www.economist.com/news/1955/11/19/parkinsons-law
  7. R. Buehler, D. Griffin, and M. Ross,
    “Exploring the ‘Planning Fallacy’: Why People Underestimate Their Task Completion Times,” Journal of Personality and Social Psychology, vol. 67, no. 3, pp. 366–381, 1994, doi: 10.1037/0022-3514.67.3.366.
  8. L. P. Leach,
    “Critical Chain Project Management Improves Project Performance,” Project Management Journal, vol. 30, no. 2, pp. 39–51, 1999, doi: 10.1177/875697289903000207.
  9. T. Raz, R. Barnes, and D. Dvir,
    “A Critical Look at Critical Chain Project Management,” Project Management Journal, vol. 34, no. 4, pp. 24–32, 2003, doi: 10.1177/875697280303400404.

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.


This site uses Just the Docs, a documentation theme for Jekyll.