用 WWA（Why-What-Acceptance）编写独立…

当你要编写结构化 backlog 条目、把特性拆成工作项，或用 Why-What-Acceptance 格式向团队传达战略意图时使用。

适用场景

解决思路

1. 定义战略层面的 Why：将工作与业务目标及团队目标连接起来。
2. 描述 What：保持描述简洁，并引用设计文件。
3. 编写 Acceptance Criteria：保持高层，不写成详细规格。
4. 确保独立性：让条目可以按任意顺序开发。
5. 保持条目可协商：邀请团队讨论，而不是把条目变成约束。
6. 让条目有价值：每个条目都交付可衡量的用户价值或业务价值。
7. 确保可测试性：结果必须可观察、可验证。
8. 合理确定大小：小到可以在一个 sprint 内估算并完成。
9. 按模板写 Title：[将交付什么]。
10. 按模板写 Why：用 1-2 句话连接战略上下文和团队目标。
11. 按模板写 What：写简短描述和设计链接，最多 1-2 段；它是对讨论的提醒，不是详细规格。
12. 按模板写 Acceptance Criteria：列出可观察结果（示例中列出 4 条）。
13. 输出完整交付物：为特性提供完整的 backlog 条目集合。
14. 确保每个条目都包含 Why、What 和 Acceptance Criteria 部分。
15. 确保条目相互独立，且可按任意顺序交付。
16. 确保条目大小适合估算，并能在单个 sprint 内完成。
17. 确保战略上下文清晰，便于团队决策。
18. 包含设计引用，为实现提供指导。

适用边界 · 注意事项

• 当需要详细规格说明或技术设计文档时，不适合仅用 WWA 替代。
• 当工作项无法拆成独立、可在一个 sprint 内完成、可交付价值的小条目时，不适合套用 WWA。