Exercise 1: A Lower Completion Rate — Possible Solution
====================================================================

SETUP
------------------------------
    ACTION_ITEM_COMPLETION_RATE = 0.3 (lowered from the chapter's own 0.5)

RESULTS
------------------------------
    A single run at completion_rate=0.3 happened to end at a backlog of
    0 - but this is misleading noise from one random run. Averaging
    2,000 trials for an honest comparison:

    Average final backlog at completion_rate=0.3: 2.37
    Average final backlog at completion_rate=0.5: 0.99

    (chapter's own single-run result at 0.5: 2; venting-only: 13)

COMPARISON
------------------------------
Both tracked-action-item rates stay dramatically better than
venting-only (13) - even a team that only follows through on 30% of
its own commitments still ends up with a small, roughly stable backlog
(2.37) rather than an ever-growing one. But the lower rate genuinely
performs worse than the chapter's own 0.5 baseline (2.37 vs. 0.99 on
average) - following through less often does have a real, measurable
cost, it just doesn't erase the entire benefit of tracking in the
first place.

WHY THIS WORKS AS AN ANSWER
------------------------------
This surfaces an important methodological point the chapter's own
single-run numbers didn't have to address: a stochastic simulation run
once can produce a misleadingly good (or bad) result purely from
chance, especially over a relatively short 10-retro window. Averaging
many trials is what separates "this specific run happened to go well"
from "this is what the process actually tends to produce" - the same
discipline this course's own sibling courses applied whenever a
random simulation was involved (Distributed Systems & Scalability's
own multiprocessing benchmarks, for instance).