Spec-Driven Development Makes Planning Poker More Important

Spec-driven development is having a moment because AI agents exposed an old truth: vague requirements do not become less vague when a model writes the code.

The recent Kiro conversation is a good example. AWS describes Kiro as an agentic coding service that turns prompts into detailed specs, then into working code, docs, and tests. GeekWire reported this month that AWS is adding Requirements Analysis to Kiro, aimed at catching contradictions and gaps in requirements before code is generated.

That is tech news, but it is also a backlog refinement lesson.

If AI agents are going to act on stories faster, teams need better ways to decide whether a story is ready. Planning poker is one of the simplest tools for doing that because it exposes uncertainty before implementation starts.

Specs do not replace estimation

Spec-driven development can make requirements clearer. It can force teams to write down acceptance criteria, design constraints, data flows, and implementation tasks. That is useful.

But a spec is not the same as shared understanding.

A generated spec can still miss the customer outcome. It can still choose the wrong product trade-off. It can still treat two separate risks as one feature. It can still be technically coherent while being too large for a sprint.

Planning poker gives the team a human checkpoint:

• Do we agree on the scope?
• Do we see the same risks?
• Is this one story or several?
• Does the spec answer the questions that matter?
• What review boundaries should surround AI-generated implementation?

If votes cluster tightly, the spec is probably understood. If votes split widely, the spec may look polished but still be hiding uncertainty.

The danger of beautiful wrong specs

AI-generated specs can feel convincing because they are structured. A clean requirements list, a design outline, and a task breakdown can create the impression that the story is ready.

That is not always true.

Common hidden problems include:

• Acceptance criteria that describe the happy path only.
• Missing error states, permissions, or audit needs.
• A feature that mixes product work with migration work.
• Dependencies on another team or vendor.
• Security review treated as a final step instead of a design constraint.
• Analytics, rollout, and support requirements left out of the estimate.

These are exactly the issues that planning poker tends to surface when the team votes independently.

Use planning poker as a spec review

For AI-assisted teams, planning poker should evolve from "pick a point number" into "stress-test the spec."

A practical workflow:

• Start with the ticket or generated spec.
• Ask AI to list assumptions, missing criteria, and likely implementation steps.
• Let the team vote privately.
• Reveal the spread.
• Ask high voters what risk they see.
• Ask low voters what simplification they assumed.
• Update the spec or split the story before assigning implementation.

This keeps AI useful while preventing it from deciding silently.

How Jira should capture the outcome

When a story has been through a spec-first planning session, Jira should preserve more than the final estimate.

Useful Jira notes might say:

• "Spec is clear for happy path; added failure states before sprint."
• "Split notification delivery from analytics reporting."
• "Five points if using existing template service; eight if new provider integration is required."
• "Agent may scaffold tests, but auth and data retention need human review."
• "Do not start implementation until product confirms retry timing."

Those notes are valuable because they turn planning poker into organizational memory. They also improve future AI-assisted planning because the model has better context to retrieve.

Where AI fits before and after the vote

AI is strong at turning raw backlog text into a draft spec. It can summarize comments, identify missing fields, and propose task breakdowns. It can also write cleaner meeting notes after the team makes a decision.

The safest pattern is:

• AI prepares context.
• Humans estimate and resolve ambiguity.
• AI documents the decision.
• Humans approve review boundaries.
• AI helps with implementation inside those boundaries.

The order matters. If the agent implements before the team resolves the estimate spread, the code can encode assumptions nobody agreed to.

What this means for Scrum teams

Scrum teams already have a place for this work: product backlog refinement. The goal is not to fully design every detail before sprint planning. The goal is to make work clear enough that the team can make a responsible forecast.

Spec-driven development can strengthen refinement by making hidden assumptions visible. Planning poker strengthens it by showing whether the team actually believes the story is understood.

Together, they form a useful loop:

• Draft the spec.
• Estimate the story.
• Discuss the spread.
• Improve the spec.
• Record the decision.
• Implement with clear review boundaries.

The bottom line

The rise of spec-driven AI tools does not make planning poker obsolete. It gives planning poker a sharper job.

When agents can build faster than teams can review, the estimate session becomes an early quality gate. It is where the team checks whether the story is real, whether the spec is honest, and whether the implementation can safely move forward.

Better specs help. Better team judgement still matters more.