Sprint planning used to eat our Wednesday mornings alive. For a 6-person team, we were consistently spending 3–4 hours just to scope and assign a two-week sprint — ticket by ticket, estimation poker, re-reading half-written Jira descriptions, relitigating scope that should've been settled in refinement. Last quarter, I ran an experiment to fix it. The result cut that meeting to under 90 minutes.

The Problem (Specific)

Our tickets came into planning half-baked. Engineers were reading acceptance criteria cold, asking clarifying questions that burned 10 minutes per story, and pointing wildly because nobody had a shared mental model of the work. The PM wrote the tickets; the engineers read them for the first time in the meeting. Classic.

The Experiment

I started pre-processing every ticket the night before planning with a single prompt pattern. Here's the actual prompt I used:

You are a senior software engineer reviewing a backlog ticket before sprint planning.

Ticket title: [TITLE]
Description: [PASTE FULL TICKET TEXT]

Do the following:
1. Summarize the goal in one sentence (engineer-facing, not PM-facing).
2. List the top 3 implementation risks or open questions.
3. Suggest a story point estimate (Fibonacci) with a one-line rationale.
4. Flag any missing acceptance criteria.

I ran this against every ticket in the candidate backlog — usually 20–25 stories — the evening before planning. Took about 25 minutes total.

What Happened

The outputs weren't perfect, but they were good enough to reframe the whole meeting. Instead of reading tickets cold, engineers walked in with a pre-circulated doc (I just dumped the AI outputs into a Notion page) that gave everyone the same starting context.

Results over 6 sprints:

• Average planning meeting length dropped from 3h 40m → 1h 25m
• Estimation variance dropped noticeably — we stopped seeing the "1 vs 8 point" splits that indicated someone hadn't read the ticket
• Two tickets per sprint on average got flagged for missing ACs before the meeting, which meant the PM could patch them in time rather than us parking the story mid-discussion

The AI didn't replace planning. It eliminated the tax of everyone getting up to speed in real time.

What Didn't Work

The model occasionally underestimated tickets that had non-obvious infrastructure dependencies — things it couldn't know without codebase context. I started appending a short "relevant system context" block to the prompt for complex stories, which helped. You have to treat the output as a first draft, not ground truth.

The Takeaway

The leverage here wasn't the AI writing the tickets or running the meeting. It was removing synchronous context-building from a synchronous meeting. That's a repeatable pattern: find the part of a meeting where everyone is just reading and processing, and do that async with AI beforehand.

The full set of prompts for sprint planning, plus debugging, code review, ADRs, and refactoring is in The AI Leverage Playbook: 50 Prompts & Workflows for Engineers. It's the exact toolkit I've built and refined over the last year. $19 at gumroad.com/l/nhltvo.