User Story Tips

User story 编写

Description

例如：

  • 解决什么问题：XXXXXXXX

  • 对软件现有功能会造成什么影响：XXXXXX

  • 实现的具体的功能：XXXXXX

  • 实现时需要考虑的技术细节：XXXXXX

DoD (Definition of Done)

例如:

  • 代码实现符合详细设计和上述描述要求，没有严重 bug

  • 代码更改要创建相应的 git pull request ，并由团队成员 review 和 approve ，测试无误后提交到开发主分支

  • 代码更改要有相应的测试用例和测试结果 (Unit testing, API testing or manual testing)，证实满足上述 description 的要求

优先级 Priority

P1(Must have) / P2(Should have) / P3(Could have) / P4(Won’t have)

估计工作量

对于比较大的 feature, 我们可以用 t-shirt size 来大致评估

  • Small (S) = 1–4 days

  • Medium (M) = 5–10 days

  • Large (L) = 10–20 days

  • Extra Large (XL) = more than 20 days

对于拆分过的 story , 我们可以根据复杂度，风险程度以及重复度用 Story point 来做工作量评估 Story Point 故事点是一种度量单位，用于表达完成特定用户故事、冲刺或产品待办事项列表项所需的总体工作量的估计。 例如可用一个常用实体的增删改查，例如用户的 CRUD 来表示一个故事点

  • Complexity: 复杂度，这项工作有多难做?

  • Risks: 风险程度，有无第三方依赖和不确定因素？

  • Repetition: 重复度，是重复性的工作，一次性的工作，还是探索性的工作？