Your Best Prompt Is a Well-Defined User Story
In the age of agentic development, user story quality directly impacts AI output. The article argues teams should invest more time in breaking down stories and writing clear acceptance criteria rather than just estimating story points. A well-defined story includes three parts: Context, Acceptance Criteria, and Technical Hypothesis. Story point estimation is valuable only when forecasting or surfacing team misalignment is needed; otherwise it can be skipped. A good story acts as a good prompt, accelerating development cycles. Relevant for engineering teams using agile/Scrum.
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).
如果你和我一样，你一定一直在思考 AI 如何重塑我们的开发工作。像 Claude Code 这样的工具已成为我日常工作流的一部分，它们极大地改变了我进行功能开发的方式。但我始终回到这一点：这些工具产生的结果质量，直接取决于你给它们的输入质量。这让我重新思考团队在待办列表细化上应该如何分配时间。
故事与提示的联系
根据我的代理式开发经验，最佳结果来自结构良好的提示。你需要清楚地描述问题，定义“完成”是什么样子，并将代理指向正确的技术方向。听起来很耳熟？这正是一个好的用户故事已经在做的事。
问题在于，很多团队把故事编写当成一项勾选活动。有人快速写个标题，也许再加一句描述，团队就进入估算。我待过的团队里，我们花在争论一个故事是 3 点还是 5 点上的时间，比实际定义工作要多。这个比例感觉不对，尤其是在 AI 代理可以接手一个写得好的故事并立刻运行的现在，更不对了。 我认为团队应该把更多细化时间花在拆解工作和编写扎实的验收标准上。不是因为我们在某篇博客里读到的“最佳实践”，而是因为它直接影响我们把故事交给开发者（或代理）时的推进速度。
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.
一个有效的简单格式
你不需要花哨的模板来写出好故事。我发现三个类别就能覆盖大部分需求：
背景（Context）
功能背后的“为什么”。这里描述你正在解决的问题或你正在满足的需求。今天什么情况不奏效？谁受影响？为什么现在这件事很重要？把它看作帮助开发者（或 AI 代理）理解全局的背景信息。没有背景，你只是丢给某人一个任务，对方却不理解目标。
验收标准（Acceptance Criteria）
判断功能完成的准则。这些标准应当具体且可测试。不要写“用户能筛选结果”，试试写“用户能按日期范围筛选结果，默认范围是最近 30 天”。你在这里越精确，开发期间的来回沟通就越少。如果你在使用 AI 代理，明确的验收标准就像护栏，使输出保持聚焦。
技术假设（Technical Hypothesis）
这里记录任何可能帮助开发者更快找到解决方案的技术细节。想想相关文件、包、API 或架构模式。你并不是在指定解决方案，而是在给团队一个先发优势。对 AI 代理来说，这种指引非常有价值。告诉它“这个功能应该使用 src/hooks/ 下现有的 useFilters 钩子”，比让它自己摸索要高效得多。
就是这样。三个部分：背景、验收标准、技术假设。你可以根据故事复杂程度调整每部分的深度，但这个结构在我的团队里作为起点效果很好。
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.
故事点何时适用（或何时不适用）
我知道故事点是许多团队敏捷开发中的标配。但我认为值得问问你的团队是否真的需要它们。如果团队需要为干系人提供时间线预测或用于发布计划，那么故事点估算确实有用。它给你一个可用于预测的速度指标。
如果你的团队确实进行估算，值得努力做到故事大小一致。当待办列表中的故事大小差异很大时，就很难有信心的预测时间线。一个包含 10 个 1 点故事的迭代，与一个包含 2 个 13 点故事的迭代，即使总点数相似，也完全不同。把工作拆分成大小一致的故事，能让你的速度更可预测，预测更可靠。
故事点估算也可以用于暴露团队内部的不一致。如果一个人觉得一个故事是 2 点，另一个人认为是 8 点，这就是一个值得探究的信号。这通常意味着某人掌握了团队其他人缺失的背景，或者存在范围上的分歧。这样的对话很有价值。
但对于不需要这些预测的团队呢？估算可能感觉像浪费时间。我待过的团队里，我们花 20 分钟争论一个大家都觉得简单的故事的点数。那 20 分钟我们本可以用来编写更好的验收标准或添加技术背景，从而真正加快工作。
我的建议：只有当你团队能从中获得真正价值时，才投入时间进行故事点估算。如果你需要预测，那就去做，并力求一致的故事大小，让这些预测有意义。如果估算有助于引出重要对话，那很好。但如果它只是团队因为“Scrum 团队都这么做”而例行的一项仪式，考虑把时间拿回来，投入到更有影响力的事情上，比如更好的故事定义。
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.
为什么现在这件事很重要
代理式开发的兴起提高了故事质量的赌注。当开发者拿到一个模糊的用户故事时，他们可以问澄清问题，翻看 Slack 历史，或拍拍队友肩膀。AI 代理无法做到这些（至少现在还做不到同样程度）。它只能基于你给的东西工作。
一个定义清晰的故事——有明确的背景、具体的验收标准和技术假设——已不仅仅是“最佳实践”。它是一个强有力的提示起点。这意味着你在细化阶段投入的故事拆解时间，会以更快、更准确的开发周期作为回报。
我在自己的项目中已经看到了这一点。从一开始就定义清晰的故事，无论是由人还是 AI 代理接手，都能更快通过开发，需要更少的修改，并产生更好的结果。在清晰度上的前期投入，能在后端省下时间。
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.
关键要点
投资故事定义，而非估算。团队花在拆解工作和编写清晰验收标准上的时间，直接影响开发速度，尤其在代理式开发时代。
使用简单的结构。背景、验收标准和技术假设，就能为你的团队（以及你的 AI 工具）提供开始所需的一切。
有意识地对待估算。故事点对于时间线预测和暴露团队不一致很有用，但并非普遍必需。把团队时间花在最有价值的地方。
把故事看作提示。你的故事读起来越好，AI 辅助开发的输出就越好。清晰的输入带来清晰的输出。