写用户故事、拆解功能或定义验收标准时，用 3 C's 和…

适用于写用户故事、将功能拆成 Backlog 条目或定义验收标准。

适用场景

解决思路

1. 收集并明确输入：$PRODUCT（产品或系统名称）、$FEATURE（要拆分为用户故事的新功能）、$DESIGN（Figma、Miro 等设计文件链接）、$ASSUMPTIONS（关键假设或上下文）。
2. 根据提供的设计和上下文分析功能。
3. 识别用户角色和不同的用户旅程。
4. 应用 3 C's 框架的 Card：为故事写简单标题和一句话说明。
5. 应用 3 C's 框架的 Conversation：详细讨论故事意图。
6. 应用 3 C's 框架的 Confirmation：写清楚验收标准。
7. 遵守 INVEST 标准：Independent、Negotiable、Valuable、Estimable、Small、Testable（独立、可协商、有价值、可估算、小、可测试）。
8. 使用小学毕业生能理解的白话。
9. 链接设计文件，供视觉参考。
10. 按结构化格式输出用户故事。
11. 使用故事模板填写 Title：[Feature name]。
12. 使用 Description 模板：As a [user role], I want to [action], so that [benefit]（作为 [user role]，我想要 [action]，以便 [benefit]）。
13. 在故事中填写 Design：[Link to design files]。
14. 在故事中填写 Acceptance Criteria，并确保覆盖清晰且可测试的标准。
15. 确保验收标准覆盖可观察行为。
16. 确保验收标准覆盖系统正确验证。
17. 确保验收标准覆盖边界情况处理。
18. 确保验收标准覆盖性能或无障碍考虑。
19. 确保验收标准覆盖集成点。
20. 输出该功能的完整用户故事集合。
21. 让每个故事都包含标题、描述、设计链接和 4-6 条验收标准。
22. 确保故事是独立的，可以按任意顺序开发。
23. 将故事大小控制在一个冲刺周期内。
24. 让故事引用相关设计文档。

适用边界 · 注意事项

• 没有可识别的用户角色、设计链接或关键上下文时，不适用；需要先补齐 $DESIGN、$ASSUMPTIONS 等输入。
• 需要的是技术实现方案、架构设计或非用户价值驱动的任务拆分时，不适用。
• 功能过大，无法拆成一个冲刺周期内的独立故事时，不适用；应先进一步拆分。