Planning Poker in the AI Era

Planning a development task matters more now than it used to. When an AI agent writes the implementation, what you get back depends almost entirely on the context you handed it before it started.

What works for humans works for AI agents

Not long ago, when humans wrote all the code, they went faster if they had well defined specifications. The same thing happens with agents.

Agents are good at implementing, as long as they have the right specs. So it is worth spending time on the technical questions and not only the product ones. Does this feature need a new library? Do we expect to reuse this module somewhere else?

Well defined specs are what speed up the development process.

What breaks when an agent gets a thin ticket

Bad specs produce bad outcomes, and bad outcomes turn into back and forth discussions that add days to shipping a feature.

If the agent does not have the full context, it will make its best guess. It will not stop to ask you what you meant.

So the developer has to go through the result carefully and work out which parts were guessed. That is the first point of failure.

Usually, when the agent gets it wrong, it is because nobody gave it the full context in the first place.

The discussion was always the point

Having everyone think about a task in a relaxed environment raises issues and makes sure the full context is taken into account.

The estimate was never the valuable output, the conversation that produced it was.

When the whole team shares what they have learned about writing tasks for agents, they can build the spec list together and pass on what actually works.

Once agents do the implementation, new questions come up in that conversation. Are we using one of our company skills here? Does this need a big model, or will a small one do the job?

Sharing that knowledge inside the team matters more now that the tooling changes every few months.

Does this mean estimating more, or estimating differently?

Someone will say AI makes estimation pointless because implementation is cheap now.

I think story points still matter. Complexity is still what tells you how long a task will take, and that has not gone away. Some tasks need longer specs and more verification, and they carry more risk.

But the real benefit of estimating, beyond the number, is making sure everyone knows what the task is about and has the context an agent needs to build it. That includes things like:

• Split the task? or merge it with another?
• Can this be shipped alone?
• Which agent skills we plan to use
• Which existing components or modules to reuse
• The UI defined in all its variations
• The mistakes the agent tends to make here, so we know what to review
• etc.

What this looks like in practice

If you want to improve how your team performs, spend more time planning.

When a task has all its context ready in advance, the implementation is almost instant. When it does not, you can lose days going back and forth with different stakeholders.

Picking a tool for your planning

Planning poker tools are built for exactly this kind of conversation.

The first thing to settle is whether your team estimates together in a meeting or on their own time, because that decides which tools are even worth looking at. I went through both options in async vs live planning poker.

If your team works in Jira, I compared the plugins in 10 best planning poker plugins for Jira, including which ones support live, async and hybrid voting.