You Cannot Tell Where a Program Spends Its Time

When you add an AI agent to your workflow, you expect it to save time on the obvious, boring stuff — writing boilerplate, triaging tickets, summarizing documents. But the real bottlenecks are rarely where you think they are.

Teams that rush to automate code generation often discover the real slowdown was never writing the code. It was reviewing it, understanding it, and deciding what to build next. AI speeds up the writing but may not touch the actual delay.

In Scrum terms: before your team celebrates because an AI assistant cut story-writing time in half, look at your flow metrics. Check your cycle time. Is the bottleneck actually in writing stories — or is it in refinement, review, or deployment? Measure first. Then decide where to apply AI.

Fancy Algorithms Are Slow When n Is Small

A large language model is, by definition, a very fancy algorithm. It has enormous constants — in compute cost, in latency, in API pricing, and in the cognitive cost of managing its outputs. When the problem is small, the fancy approach loses.

Does your team need an AI agent to summarize a ten-line daily standup update? Probably not. Does it make sense to use a multi-step reasoning agent to answer a question that a simple regex or a SQL query would answer in milliseconds? No.

This rule teaches us to ask the right question before reaching for a powerful tool: Is n actually big here? For Scrum teams, AI starts to earn its keep on truly large inputs — analyzing hundreds of production defects to find patterns, suggesting relative effort estimates across a backlog of sixty or more items, or synthesizing user research from dozens of interviews. Keep small tasks small.

Data Dominates

This might be the most important rule in the age of AI — and the most ignored. AI models are, at their core, a reflection of the data they were trained on. Large language models generate outputs based on patterns in their training data. Agents retrieve, process, and act on the data you give them. The quality of that data determines everything.

In an Agile context, your Product Backlog is data. Your acceptance criteria are data. Your Definition of Done is data. If those are unclear, inconsistent, or poorly structured, an AI agent working with them will produce unclear, inconsistent, or poorly structured outputs — with great confidence and beautiful formatting.

Pike's rule translates directly: before you invest in a better AI model or a smarter agent, invest in better structured data. Clean up your Jira tickets. Write acceptance criteria in consistent formats. Structure your test cases so they can be read by a machine. When your data is good, even a simpler model will do impressive work. When your data is messy, no model saves you.

• Well-structured user stories feed better AI suggestions
• Consistent acceptance criteria format enables reliable agent parsing
• Clean sprint history gives AI more accurate context for estimates
• Data hygiene is now a team responsibility — not just a DBA problem