📋 Scheduling Estimates

Option B is the professional estimate delivery. It: (1) states the range clearly (3-5 days), (2) names the assumptions ("assuming requirements stay stable and no blockers") — this is critical; estimates without stated assumptions are commitments without conditions, (3) explains what drives each bound — the lower bound assumes best case (straightforward API); upper bound accounts for edge cases, (4) recommends planning for the upper bound — this is the professional default for schedule risk management. Option A adds "I'm not sure" without any structure — sounds unprepared. Option C expands the range arbitrarily ("a week or more") without reason — unhelpful. Option D defers the estimate entirely — this may be valid sometimes but often just delays the same uncertainty.

Option B correctly explains story points. Key concepts: (1) relative sizing — story points compare stories to each other, not to calendar time, (2) velocity — the team's historical throughput (points per sprint) is what converts points to time estimates, (3) team-specific — a 5-point story for one team may be very different work than a 5-point story for another team, (4) the intentional abstraction from calendar days removes pressure and focuses estimation on complexity, uncertainty, and relative effort. Option A ("5 points = 5 days") is a common misconception — story points specifically avoid this mapping. Option C ("1 SP = 1 ideal day") is the outdated original XP definition that most modern teams reject. Option D is cynical and not useful as an explanation.

Option B correctly defines T-shirt sizing. It's a pre-refinement estimation tool: (1) use case: when work items are too vague to estimate in story points (no acceptance criteria, unclear scope), T-shirt sizes communicate rough magnitude, (2) sizes: XS = hours/1-2 days; S = 2-5 days; M = 1-2 weeks; L = 2-4 weeks; XL = 1+ month; XXL = needs to be broken down, (3) roadmap planning: T-shirt sizes help business stakeholders understand initiative scope without committing to specific estimates, (4) progression: T-shirt sizes are refined to story points during sprint planning as stories are broken down. Option A is completely wrong. Option C confuses team sizing with work sizing. Option D has no basis.

Option B identifies a real and important timezone ambiguity. In distributed teams, "EOD" is one of the most commonly misunderstood time references: (1) sender's EOD vs. receiver's EOD — an 8+ hour difference is a missed deadline or unnecessary overnight crunch, (2) clarification is professional — asking "whose EOD?" demonstrates time zone awareness, (3) better alternatives: use specific times with timezone ("by 5pm UTC Thursday") or absolute references ("by Thursday 17:00 London time"). Option A assumes a single timezone. Option C is wrong. Option D is wrong. This exercise teaches a real professional communication skill: timezone-aware deadline communication.

Option B is the professionally mature retrospective response. It: (1) "based on information available at the time" — this is the critical frame: estimates are made under uncertainty, not guaranteed, (2) names the specific complexity that wasn't visible — this is the actionable learning, (3) proposes a process improvement (spike for uncertain areas before sizing), (4) "the estimate wasn't wrong given the information we had" — this protects estimation culture from becoming blame culture. If estimates are punished as "wrong" when complexity is discovered, teams respond by padding all estimates defensively, which destroys the planning signal. Option A treats the estimate as definitively wrong without acknowledging uncertainty. Option C blames the person. Option D discards a useful practice based on one data point.