🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🎲 धडा 05 — नियोजन आणि अंदाज: Monte Carlo forecast विरुद्ध एकच तारीख

📍 तुम्ही इथे आहात: 12 पैकी धडा 05 · मागे: lesson-04-hiring · पुढे: lesson-06-prioritisation

📦 या ब्रँचमध्ये काय आहे

धडा 04, आणि "हे कधी पूर्ण होईल?" याचे प्रामाणिक उत्तर. सरासरीवरून काढलेली एकच तारीख बहुतेक वेळा नाणेफेक का असते, आणि टीमच्या स्वतःच्या मागील throughput वरून बनवलेला Monte Carlo forecast संभाव्यतेसह range कशी देतो: 50% तारीख, 85% तारीख आणि 95% तारीख. lead/demo.py मधले forecast(); lead/models.py मधले monte_carlo() आणि pct().

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

मुख्याध्यापिका कतरिनाला विचारतात: "विभाग सगळ्या 40 उत्तरपत्रिका तपासून कधी पूर्ण करेल?" 📚

कतरिना मागचे दहा आठवडे पाहते. काही आठवड्यांत विभागाने 6 किंवा 7 तपासणीची कामे पूर्ण केली. एका आठवड्यात — क्रीडा सप्ताहात — एकही नाही. सरासरी, आठवड्याला जवळपास 3.7.

सोपे उत्तर: "40 ÷ 3.7 ≈ 11 आठवडे." पण यात असे गृहीत धरले आहे की प्रत्येक आठवडा सरासरी आठवडा असेल. काही आठवडे संथ असतील. 🐢

म्हणून कतरिना एक खेळ खेळते. 🎲 ती मागचे दहा आठवडे दहा पत्त्यांवर लिहिते. ती यादृच्छिकपणे एक पत्ता काढते — तो "पुढचा आठवडा". ती तपासणीची बेरीज करते, पुन्हा पत्ता काढते, पुन्हा, 40 उत्तरपत्रिका पूर्ण होईपर्यंत. ती आठवडे मोजते. मग ती संपूर्ण खेळ 10,000 वेळा खेळते (computer मदत करतो!).

अर्धे खेळ 11 आठवड्यांत किंवा कमी वेळात संपतात. पण 100 पैकी 85 खेळ 13 आठवड्यांत किंवा कमी वेळात संपतात. म्हणून ती मुख्याध्यापिकांना सांगते: "11 आठवडे म्हणजे नाणेफेक. तुम्हाला बऱ्यापैकी खात्री हवी असेल तर 13 चे नियोजन करा."

🗺️ आकृती

flowchart LR
    h["📒 last 10 weeks<br/>2 6 1 4 7 0 5 3 6 3<br/>average 3.7"] --> g["🧮 single guess<br/>40 ÷ 3.7 ≈ 11 weeks"]
    g --> c["58% chance<br/>of finishing by then"]
    h --> mc["🎲 10,000 seeded trials<br/>replay random past weeks"]
    mc --> r["50%: 11 wk · 85%: 13 wk · 95%: 15 wk"]
    r --> s["📈 backlog +20% → 48 items<br/>50%: 13 wk · 85%: 16 wk"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/engineering-leadership/lesson-diagrams.html#l05

❓ काय

Estimate विरुद्ध forecast — estimate कामाच्या आकाराचा अंदाज करतो ("हे 3 दिवसांचे आहे"). Forecast पुराव्यावरून, सांगितलेल्या संभाव्यतेसह, तारीख वर्तवतो. प्रत्येक काम estimate न करताही तुम्ही forecast करू शकता — कामे ज्या दराने पूर्ण होत आली आहेत त्यावरून.
Throughput — टीम दर आठवड्याला किती कामे पूर्ण करते. हे मोजले जाते, अंदाजले जात नाही, म्हणून त्यात meetings, आजारपणाचे दिवस, bugs आणि व्यत्यय आधीच समाविष्ट असतात.
Monte Carlo simulation — एखादी यादृच्छिक प्रक्रिया अनेक वेळा चालवा आणि निकालांचा पसारा पाहा. इथे: backlog पूर्ण होईपर्यंत प्रत्येक भावी आठवड्यासाठी मागील एखाद्या यादृच्छिक आठवड्याचा throughput निवडा; हे 10,000 वेळा करा. या पद्धतीचे वर्णन Troy Magennis आणि Daniel Vacanti यांसारख्या practitioners नी केले आहे.
Percentile dates — 50% तारीख म्हणजे median: तोपर्यंत अर्धे trials पूर्ण झाले. 85% तारीख: तोपर्यंत 100 पैकी 85 trials पूर्ण झाले. परिस्थितीला किती खात्री हवी ते lead निवडते — ठरलेल्या परीक्षेच्या तारखेला अंतर्गत target पेक्षा जास्त खात्री लागते.
एकाच तारखेचा सापळा — backlog ला सरासरी throughput ने भागल्यास साधारण median मिळतो: जवळपास 50/50 शक्यता. ते "ती तारीख" म्हणून मांडल्याने नाणेफेक लपते.
गृहीतके (दर वेळी लिहून ठेवा): भविष्य अलीकडच्या भूतकाळासारखे असेल; कामे साधारण सारख्या आकाराची आहेत, किंवा किमान त्याच प्रकारे मिसळलेली; आठवडे एकमेकांवर अवलंबून नाहीत; backlog ची संख्या प्रामाणिक आहे. काम समजत जाते तसे backlog सहसा वाढतो — तसे झाल्यावर पुन्हा forecast करा.

🤔 का

कारण एकच तारीख वचन म्हणून ऐकली जाते, आणि सरासरीवर आधारलेले वचन जवळपास अर्ध्या वेळा चुकते — ज्यामुळे सगळे शिकतात की अंदाज निरुपयोगी असतात. संभाव्यतेसह range तुमच्यावर अवलंबून असलेल्यांना नियोजन करू देते: "आठवडा 13 पर्यंत 85%" हे मुख्याध्यापिकांना त्या किती धोका बाळगत आहेत ते सांगते. आणि forecast मोजलेल्या throughput वरून बनत असल्याने, त्याला लांबलचक estimation meetings लागत नाहीत.

🔧 कसे (या repo मध्ये)

lead/models.py मधले monte_carlo(history, backlog, trials=10000, seed=42) छोटा seeded random generator Rng वापरते, म्हणून प्रत्येक run तेच आकडे print करतो. प्रत्येक trial साठी ते पूर्ण झालेली कामे backlog पर्यंत पोहोचेपर्यंत history मधून यादृच्छिक आठवडे काढते, आणि आठवड्यांची संख्या नोंदवते. ते sorted list परत देते; pct(runs, p) त्यातून percentile वाचते. lead/demo.py मधले forecast() एकाच अंदाजाची 50/85/95% तारखांशी आणि 20% ने वाढणाऱ्या backlog शी तुलना करते. विचार करण्याचे साधन, माणसांसाठीचे सूत्र नाही: ते कामाच्या system चा forecast करते, आणि त्याचे कधीही व्यक्तींसाठीच्या target मध्ये रूपांतर होता कामा नये.

🧪 करून पाहा

python3 lead/demo.py forecast
python3 - <<'EOF'
import sys; sys.path.insert(0, "lead"); from models import monte_carlo, pct
hist = [2, 6, 1, 4, 7, 0, 5, 3, 6, 3]
for backlog in (20, 40, 60):
    r = monte_carlo(hist, backlog)
    print(f"backlog {backlog:>2} → 50%: {pct(r, .5):>2} wk · 85%: {pct(r, .85):>2} wk · 95%: {pct(r, .95):>2} wk · single guess {round(backlog / 3.7):>2} wk")
for seed in (1, 2, 3):
    r = monte_carlo(hist, 40, seed=seed)
    print(f"seed {seed} → 50%: {pct(r, .5)} · 85%: {pct(r, .85)}")
steady = monte_carlo([4, 4, 3, 4, 4, 3, 4, 4, 3, 4], 40)
print(f"a steadier team, same 3.7 average → 50%: {pct(steady, .5)} · 85%: {pct(steady, .85)} · 95%: {pct(steady, .95)}")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

forecast असे print करते:

── the last 10 weeks' throughput (items finished): [2, 6, 1, 4, 7, 0, 5, 3, 6, 3] · average 3.7/week · backlog 40 items
   the single-date guess: 40 ÷ 3.7 ≈ 11 weeks
   Monte Carlo, 10,000 seeded trials replaying random past weeks → 50%: 11 weeks · 85%: 13 weeks · 95%: 15 weeks
   chance of finishing within the guess (11 weeks): 58%
── the backlog grows 20% (40 → 48 items) → 50%: 13 weeks · 85%: 16 weeks

तुमचा snippet असे print करतो:

backlog 20 → 50%:  6 wk · 85%:  7 wk · 95%:  9 wk · single guess  5 wk
backlog 40 → 50%: 11 wk · 85%: 13 wk · 95%: 15 wk · single guess 11 wk
backlog 60 → 50%: 17 wk · 85%: 19 wk · 95%: 21 wk · single guess 16 wk
seed 1 → 50%: 11 · 85%: 13
seed 2 → 50%: 11 · 85%: 13
seed 3 → 50%: 11 · 85%: 13
a steadier team, same 3.7 average → 50%: 11 · 85%: 12 · 95%: 12

🏁 तुम्ही आत्ताच काय सिद्ध केले

एकच अंदाज (11 आठवडे) median वर बसतो: तो पाळला जाण्याची फक्त 58% शक्यता. 85% तारीख 13 आठवडे आणि 95% तारीख 15 आहे. वेगवेगळे seeds तेच उत्तर देतात, म्हणून या history साठी 10,000 trials पुरेसे आहेत. त्याच सरासरीची अधिक स्थिर टीम खूप अरुंद range देते (आठवडा 12 पर्यंत 85%) — अंदाज वर्तवता येणे कमी चढउतारातून येते, जास्त सरासरीतून नाही. आणि 20% मोठ्या backlog ने 85% तारीख 13 वरून 16 आठवड्यांवर नेली.

⚠️ नेहमीच्या चुका

संभाव्यतेशिवाय एकच तारीख देणे, आणि ती वचन म्हणून पुन्हा पुन्हा ऐकणे
मोजलेल्या throughput ऐवजी आदर्श क्षमतेवरून forecast करणे ("5 लोक × 5 दिवस")
खूप वेगवेगळ्या आकारांची कामे (एक तासाचा fix आणि दोन महिन्यांचा project) एकाच मोजणीत मिसळणे
एकदाच forecast करणे आणि पुन्हा कधीच नाही — history आणि backlog बदलतात तसा तो दर आठवड्याला पुन्हा चालवा
forecast चे व्यक्तींसाठीच्या target मध्ये रूपांतर करणे (targets काय करतात ते धडा 08 दाखवतो)
backlog वाढेल हे विसरणे: काम समजत जाते तशी नवी कामे दिसतात

🏭 प्रत्यक्ष वापरात

Throughput म्हणजे दर आठवड्याला पूर्ण झालेल्या कामांची संख्या, जी बहुतेक trackers export करू शकतात. खऱ्या repository वर, दर आठवड्याला merge झालेले pull requests हा ढोबळ पर्याय आहे (एक काम म्हणजे अनेक PRs असू शकतात — हे गृहीतक नोंदवा):

gh pr list --state merged --limit 200 --json mergedAt \
  --jq '.[].mergedAt[0:10]' | sort | uniq -c | tail -20

संपूर्ण forecast तुमच्या स्वतःच्या script च्या काही ओळींत, किंवा spreadsheet मध्ये बसतो:

import random
def forecast(history, backlog, trials=10_000):
    runs = []
    for _ in range(trials):
        done = weeks = 0
        while done < backlog:
            done += random.choice(history); weeks += 1
        runs.append(weeks)
    runs.sort()
    return {p: runs[int(p / 100 * trials) - 1] for p in (50, 85, 95)}

लोकांना असे सांगा:

Gradebook migration — forecast, week 14
40 items left · based on the last 10 weeks' throughput
50%: week 25 · 85%: week 27 · 95%: week 29
Assumptions: similar item mix; no new scope; Leela joins on-call in week 18.
Next re-forecast: Monday.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: "हे 14 तारखेला पूर्ण होईल" ऐवजी "21 तारखेपर्यंत 85%, दर आठवड्याला पुन्हा forecast" असे म्हणा. लोक range भोवती नियोजन करू शकतात; अर्ध्या वेळा बरोबर ठरणाऱ्या तारखेभोवती ते नियोजन करू शकत नाहीत.

⏭️ पुढे

Forecast ने असे गृहीत धरले की आधी काय करायचे हे तुम्हाला आधीच माहीत आहे. पुढे: क्रम ठरवणे — prioritisation, गृहीतके दृश्य करून.

git checkout lesson-06-prioritisation

🎲 Lesson 05 — Planning and estimation: a Monte Carlo forecast vs a single date

📍 You are here: Lesson 05 of 12 · Previous: lesson-04-hiring · Next: lesson-06-prioritisation

📦 What's in this branch

Lesson 04, plus answering "when will it be done?" honestly. Why a single date made from an average is usually a coin flip, and how a Monte Carlo forecast built from the team's own past throughput gives a range with a probability: a 50% date, an 85% date and a 95% date. forecast() in lead/demo.py; monte_carlo() and pct() in lead/models.py.

🧒 Explain like I'm 5

The head teacher asks Katrina: "When will the department finish marking all 40 exam papers?" 📚

Katrina looks at the last ten weeks. Some weeks the department finished 6 or 7 pieces of marking. One week — sports week — it finished none. On average, about 3.7 a week.

The easy answer: "40 ÷ 3.7 ≈ 11 weeks." But that assumes every week will be an average week. Some weeks will be slow. 🐢

So Katrina plays a game. 🎲 She writes the ten past weeks on ten cards. She draws a card at random — that is "next week". She adds up the marking, draws again, and again, until 40 papers are done. She counts the weeks. Then she plays the whole game 10,000 times (a computer helps!).

Half the games finish in 11 weeks or less. But 85 games out of 100 finish in 13 weeks or less. So she tells the head teacher: "11 weeks is a coin flip. If you need to be fairly sure, plan for 13."

🗺️ Diagram

flowchart LR
    h["📒 last 10 weeks<br/>2 6 1 4 7 0 5 3 6 3<br/>average 3.7"] --> g["🧮 single guess<br/>40 ÷ 3.7 ≈ 11 weeks"]
    g --> c["58% chance<br/>of finishing by then"]
    h --> mc["🎲 10,000 seeded trials<br/>replay random past weeks"]
    mc --> r["50%: 11 wk · 85%: 13 wk · 95%: 15 wk"]
    r --> s["📈 backlog +20% → 48 items<br/>50%: 13 wk · 85%: 16 wk"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/engineering-leadership/lesson-diagrams.html#l05

❓ What

Estimate vs forecast — an estimate guesses the size of work ("this is 3 days"). A forecast predicts a date from evidence, with a stated probability. You can forecast without estimating every item — from the rate items have been finishing.
Throughput — how many work items the team finishes per week. It is counted, not guessed, so it already includes meetings, sick days, bugs and interruptions.
Monte Carlo simulation — run a random process many times and look at the spread of results. Here: pick a random past week's throughput for each future week until the backlog is done; repeat 10,000 times. The approach is described by practitioners such as Troy Magennis and Daniel Vacanti.
Percentile dates — the 50% date is the median: half the trials finished by then. The 85% date: 85 of 100 trials finished by then. A lead chooses which confidence the situation needs — a fixed exam date needs more than an internal target.
The single-date trap — dividing the backlog by the average throughput gives roughly the median: about a 50/50 chance. Presenting that as "the date" hides a coin flip.
The assumptions (write them down every time): the future resembles the recent past; items are roughly similar in size, or at least mixed the same way; weeks are independent; the backlog count is honest. Backlogs usually grow as work is understood — re-forecast when they do.

🤔 Why

Because a single date is heard as a promise, and a promise built on an average is missed about half the time — which teaches everyone that estimates are worthless. A range with a probability lets the people who depend on you plan: "85% by week 13" tells the head teacher how much risk she is holding. And because the forecast is built from counted throughput, it needs no long estimation meetings.

🔧 How (in this repo)

monte_carlo(history, backlog, trials=10000, seed=42) in lead/models.py uses the tiny seeded random generator Rng, so every run prints the same numbers. For each trial it draws random weeks from history until the finished items reach backlog, and records the number of weeks. It returns the sorted list; pct(runs, p) reads a percentile from it. forecast() in lead/demo.py compares the single guess with the 50/85/95% dates and a backlog that grows by 20%. A thinking tool, not a formula for people: it forecasts the work system, and must never be turned into a target for individuals.

🧪 Try it

python3 lead/demo.py forecast
python3 - <<'EOF'
import sys; sys.path.insert(0, "lead"); from models import monte_carlo, pct
hist = [2, 6, 1, 4, 7, 0, 5, 3, 6, 3]
for backlog in (20, 40, 60):
    r = monte_carlo(hist, backlog)
    print(f"backlog {backlog:>2} → 50%: {pct(r, .5):>2} wk · 85%: {pct(r, .85):>2} wk · 95%: {pct(r, .95):>2} wk · single guess {round(backlog / 3.7):>2} wk")
for seed in (1, 2, 3):
    r = monte_carlo(hist, 40, seed=seed)
    print(f"seed {seed} → 50%: {pct(r, .5)} · 85%: {pct(r, .85)}")
steady = monte_carlo([4, 4, 3, 4, 4, 3, 4, 4, 3, 4], 40)
print(f"a steadier team, same 3.7 average → 50%: {pct(steady, .5)} · 85%: {pct(steady, .85)} · 95%: {pct(steady, .95)}")
EOF

✅ Verify — what you should see

forecast prints:

── the last 10 weeks' throughput (items finished): [2, 6, 1, 4, 7, 0, 5, 3, 6, 3] · average 3.7/week · backlog 40 items
   the single-date guess: 40 ÷ 3.7 ≈ 11 weeks
   Monte Carlo, 10,000 seeded trials replaying random past weeks → 50%: 11 weeks · 85%: 13 weeks · 95%: 15 weeks
   chance of finishing within the guess (11 weeks): 58%
── the backlog grows 20% (40 → 48 items) → 50%: 13 weeks · 85%: 16 weeks

Your snippet prints:

backlog 20 → 50%:  6 wk · 85%:  7 wk · 95%:  9 wk · single guess  5 wk
backlog 40 → 50%: 11 wk · 85%: 13 wk · 95%: 15 wk · single guess 11 wk
backlog 60 → 50%: 17 wk · 85%: 19 wk · 95%: 21 wk · single guess 16 wk
seed 1 → 50%: 11 · 85%: 13
seed 2 → 50%: 11 · 85%: 13
seed 3 → 50%: 11 · 85%: 13
a steadier team, same 3.7 average → 50%: 11 · 85%: 12 · 95%: 12

🏁 What you just proved

The single guess (11 weeks) sits at the median: only a 58% chance of being met. The 85% date is 13 weeks and the 95% date 15. Different seeds give the same answer, so 10,000 trials is enough for this history. A steadier team with the same average has a much narrower range (85% by week 12) — predictability comes from less variation, not from a higher average. And a 20% bigger backlog moved the 85% date from 13 to 16 weeks.

⚠️ Common mistakes

giving one date with no probability, and hearing it repeated as a commitment
forecasting from ideal capacity ("5 people × 5 days") instead of counted throughput
mixing very different item sizes (a one-hour fix and a two-month project) in one count
forecasting once and never again — re-run it every week as history and backlog change
turning the forecast into a target for individuals (lesson 08 shows what targets do)
forgetting that the backlog will grow: new items appear as work is understood

🏭 In production

Throughput is a count of finished items per week, which most trackers can export. On a real repository, merged pull requests per week are a rough stand-in (one item may be several PRs — note that assumption):

gh pr list --state merged --limit 200 --json mergedAt \
  --jq '.[].mergedAt[0:10]' | sort | uniq -c | tail -20

The whole forecast fits in a few lines of your own script, or a spreadsheet:

import random
def forecast(history, backlog, trials=10_000):
    runs = []
    for _ in range(trials):
        done = weeks = 0
        while done < backlog:
            done += random.choice(history); weeks += 1
        runs.append(weeks)
    runs.sort()
    return {p: runs[int(p / 100 * trials) - 1] for p in (50, 85, 95)}

Say it to people like this:

Gradebook migration — forecast, week 14
40 items left · based on the last 10 weeks' throughput
50%: week 25 · 85%: week 27 · 95%: week 29
Assumptions: similar item mix; no new scope; Leela joins on-call in week 18.
Next re-forecast: Monday.

🏭 Why this matters in production: replace "it will be done on the 14th" with "85% by the 21st, re-forecast weekly". People can plan around a range; they cannot plan around a date that is right half the time.

⏭️ Next

The forecast assumed you already know what to do first. Next: deciding the order — prioritisation, with the assumptions made visible.

git checkout lesson-06-prioritisation

← Previoushiring Next →prioritisation

This page is the lesson's README from the lesson-05-forecasting branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.