If you’re anything like me, you’ve been thinking a lot about how AI is reshaping the way we work as developers. Tools like Claude Code have become part of my daily workflow, and they’ve changed how I approach feature development in a big way. But here’s the thing I keep coming back to: the quality of what these tools produce is directly tied to the quality of what you give them. And that has me rethinking how teams should spend their time during backlog refinement.
The Connection Between Stories and Prompts
In my experience with agentic development, the best results come from well-structured prompts. You need to clearly describe the problem, define what “done” looks like, and point the agent in the right technical direction. Sound familiar? That’s essentially what a good user story already does.
The problem is that many teams treat story writing as a checkbox activity. Someone writes a quick title, maybe a one-liner description, and the team moves on to estimation. I’ve been on teams where we spend more time debating whether something is a 3 or a 5 than we do actually defining the work. That ratio feels off, and it feels especially off now that AI agents can take a well-written story and run with it.
I think teams should be spending more of their refinement time breaking down work and writing solid acceptance criteria. Not because it’s a best practice we read about in a blog post somewhere, but because it directly impacts how fast we can move when we hand that story off to a developer (or an agent).
A Simple Format That Works
You don’t need a fancy template to write good stories. I’ve found that three categories cover most of what you need:
Context
The “why” behind the feature. This is where you describe the problem you’re solving or the need you’re addressing. What’s happening today that isn’t working? Who is affected? Why does this matter now? Think of this as the background information that helps a developer (or an AI agent) understand the bigger picture. Without context, you’re just handing someone a task with no understanding of the goal.
Acceptance Criteria
The guidelines for considering the feature complete. These should be specific and testable. Instead of “the user can filter results,” try something like “the user can filter results by date range, and the default range is the last 30 days.” The more precise you are here, the less back-and-forth you’ll have during development. And if you’re using an AI agent, clear acceptance criteria act as guardrails that keep the output focused.
Technical Hypothesis
Where you capture any technical details that might help guide the developer toward a solution faster. Think relevant files, packages, APIs, or architectural patterns. You’re not prescribing the solution, but you’re giving the team a head start. For an AI agent, this kind of direction is incredibly valuable. Telling it “this feature should use the existing `useFilters` hook in `src/hooks/`” is a lot more productive than letting it figure that out on its own.
That’s it. Three sections. Context, Acceptance Criteria, and Technical Hypothesis. You can adapt the depth of each section based on the complexity of the story, but this structure has worked well as a starting point for my teams.
Where Story Points Fit (Or Don’t)
I know story points are a staple of agile development for a lot of teams. But I think it’s worth asking whether your team actually needs them. If your team needs timeline projections for stakeholders or release planning, then yes, story point estimation serves a purpose. It gives you a velocity metric you can use to forecast.
If your team does estimate, one thing worth striving for is consistent story sizing. When your backlog has a huge variety of story sizes, it becomes really difficult to project timelines with any confidence. A sprint with ten 1-pointers looks nothing like a sprint with two 13-pointers, even if the total points are similar. Breaking work down into consistently sized stories makes your velocity more predictable and your forecasts more reliable.
Story point estimation can also be useful for surfacing misalignment within the team. If one person thinks a story is a 2 and another thinks it’s an 8, that’s a signal worth exploring. It usually means someone has context that the rest of the team is missing, or there’s a disagreement about scope. That conversation is valuable.
But for teams that don’t need those projections? Estimation can feel like time wasted. I’ve been on teams where we spend 20 minutes debating points on a story that everyone agrees is straightforward. That’s 20 minutes we could have spent writing better acceptance criteria or adding technical context that would actually speed up the work.
My suggestion: only invest time in story point estimation if your team is getting real value from it. If you need the projections, do it, and aim for consistent sizing to make those projections meaningful. If estimation helps surface important conversations, great. But if it’s just a ritual your team goes through because “that’s what scrum teams do,” consider reclaiming that time for something more impactful, like better story definition.
Why This Matters Now
The rise of agentic development has raised the stakes on story quality. When a developer picks up a vague user story, they can ask clarifying questions, dig through Slack history, or tap a teammate on the shoulder. An AI agent can’t do that (at least not yet in the same way). It works with what you give it.
A well-defined story with clear context, specific acceptance criteria, and a technical hypothesis isn’t just good practice anymore. It’s a strong starting point for a prompt. And that means the time you invest in story breakdown during refinement pays off in faster, more accurate development cycles.
I’ve seen this play out on my own projects. Stories that are well-defined from the start move through development faster, require fewer revisions, and produce better outcomes, whether a human or an AI agent picks them up. The upfront investment in clarity saves time on the back end.
Key Takeaways
Invest in story definition over estimation. The time your team spends breaking down work and writing clear acceptance criteria has a direct impact on development speed, especially in the age of agentic development.
Use a simple structure. Context, Acceptance Criteria, and Technical Hypothesis give your team (and your AI tools) everything they need to get started.
Be intentional about estimation. Story points are useful for timeline projections and surfacing misalignment, but they’re not universally necessary. Spend your team’s time where it adds the most value.
Think of stories as prompts. The better your story reads, the better your AI-assisted development output will be. Clear inputs lead to clear outputs.