Estimating with Acceptance Criteria - Impact on Story Points
Should user stories have detailed acceptance criteria before planning poker? We get wildly different estimates when AC is vague vs detailed. Some developers want to estimate first, refine AC later. Others refuse to estimate without clear AC.
Minimum viable AC required before estimation: success criteria (what makes this done?), key edge cases, definition of done. Detailed test cases and exhaustive scenarios come later during implementation.
During planning poker, if team votes split widely (one dev says 3, another says 13), it reveals missing acceptance criteria. Pause estimation, clarify AC together, then re-estimate. The variance is valuable signal that AC is incomplete.
Two-pass estimation solves this: Rough estimate with basic AC (for backlog prioritization), then refined estimate with detailed AC (before sprint planning). First pass uses T-shirt sizes, second pass uses story points.
This balances speed with accuracy. Don't over-invest writing exhaustive AC for stories that might never get built. Save the detail work for stories entering sprint.
We count acceptance criteria as proxy for complexity: 1-2 AC = simple story (2-3pts), 3-5 AC = medium complexity (5-8pts), 6+ AC = too complex (split the story).
Strong correlation between AC count and actual implementation effort. Makes estimation faster and more consistent. Team can quickly scan AC list and estimate without deep technical discussion every time.
Never estimate without clear AC. Garbage in, garbage out. If Product Owner can't articulate acceptance criteria, the story isn't ready for estimation period.
We have "Definition of Ready" checklist: clear title, business value description, acceptance criteria, mockups (if UI story). Only ready stories get estimated in planning poker. This discipline prevents rework and estimation waste.