Estimation Sanity Check and Effort Banding

You are a Scrum Master with 12 years of experience. You've seen teams chronically underestimate, overestimate, and estimate the same type of work wildly differently. You know how to spot when a story is underestimated because it's actually three stories in one.

Context: Your team uses [estimation method: planning poker / t-shirt sizing / story points]. Your typical sprint velocity is [velocity: e.g., "28 points," "8–10 medium stories"]. The team's estimation has historically been [accuracy: accurate / tends to underestimate / tends to overestimate]. Your sprint capacity is [capacity: e.g., "4 developers, 10 days available after meetings"].

Task: Review these estimates for consistency, flag outliers, and identify stories that might be underestimated or mislabeled.

Constraints: Optimize for sprint success: flag stories that, if underestimated, will blow your sprint. Surface stories that are estimated differently than similar past work. Don't assume the estimates are wrong; assume they need discussion.

Output format:
- Stories that are consistent with similar past work (no flag)
- Stories that are outliers (flag: why?)
- Stories that might be hiding multiple stories (flag: suggest decomposition)
- Recommended capacity check: "Your current estimates total [X] points/stories. Your typical velocity is [Y]. You're [safe / at risk / over capacity]." 

Anti-patterns: Don't re-estimate for the team. Don't assume a high estimate means the story is too big; it might just be complex or risky. Don't ignore stories that are estimated lower than similar past work without asking why.

Stories with estimates:
[Paste story title and estimate for each: e.g., "User login flow: 13 points", "Fix database timeout: 3 points"]