如何在 Scrum 中编写好用户故事?

如何在 Scrum 中编写好用户故事?

大约70%的技术项目失败。几十年来，人们普遍认为，项目之所以失败，是因为它们没有遵循最佳实践，也没有团队中所有正确的技能。然而，最佳实践、技能和能力的采用几十年来一直在改进——那么为什么项目仍然失败呢？

 

考虑到 70% 的软件项目由于需求不佳而失败。与这些故障相关的估计返工每年超过 450 亿美元。

 

Do 70% of Your Projects Fail? (Part 1) — Pie

问题是——为什么会发生这种情况？答案是双重的。首先，业务需求往往会失去对客户的关注；其次，需求缺乏一个整体的参考框架，使需求分析师能够驱动和跟踪从客户需求、战略到正在实施的解决方案的需求。

为了编写好的需求或用户故事，请按照以下步骤操作：

1) 定义尽可能多的角色来代表系统的用户。这将帮助您专注于客户，并根据客户需求推动和跟踪需求。由 Alan Cooper 首次引入的角色定义了系统的原型用户，即与系统交互的那种人的例子。用户不必是或代表个人。用户也可以代表一个组织。

2）确保你的用户故事符合“3Cs”：

Minimum Viable Product Development - Define User Stories - PART 1 - Blog Systango

  • 卡片 (Card) – 应放在索引卡片上或贴上便笺
  • 对话 (Conversation) – 从产品负责人处获取详细信息
  • 确认 (Confirmation) ——确保它被正确实施。必须满足用户接受标准。

3) 拆分用户故事，使其大小适合包含在冲刺中。拆分故事的一些方法包括：

  • 按工艺步骤拆分
  • 按输入/输出通道分割
  • 按用户选项拆分
  • 按角色拆分
  • 按数据范围拆分

4) 让每个用户故事都遵循 INVEST 助记符：

User stories: a comprehensive guide - Justinmind

敏捷的 INVEST 助记符由 Bill Wake 创建，作为遵循的指导方针，以确保高质量的产品待办列表项 (PBI)，通常以用户故事格式编写。

独立 (Independent)：  故事应该尽可能独立。

可协商 (Negotiable)：  故事不是合同。故事是对话的邀请。这个故事抓住了想要的东西的本质。

有价值的 (Valuable)：  如果一个故事没有明显的价值，就不应该做。

可估计 (Estimable)：一个故事必须能够被估计或调整大小，以便可以适当地确定优先级。

小 (Small)：  两周迭代，允许用户故事平均 3-4 天的工作 – 总计！这包括使故事达到“完成”状态的所有工作。用户故事越小，估计的准确性就越高！

可测试 (Testable)：  每个故事都需要可测试才能“完成”。