选择分类
  • 云瑞原创
  • Mockups
  • Ui Kits
  • 背景纹理
  • 图标
  • 平面图形
  • 探索
  • 笔刷
  • 图层样式
  • PPT模版
  • 影视素材
  • 教程
  • C4D资源
  • PS动作
  • 常用3D资源
  • 字体
  • 网站模板
  • LR预设
  • 设计学院

如何为你的用户故事编写验收标准

how-to-write-acceptance-criteria-user-stories

几乎每个PM和产品积压所有者都会以这样或那样的方式使用验收标准。它们帮助我们澄清需求,提供方向,并在审查最终工作项目时提供一个检查表。

然而,验收标准并不是一成不变的。它们有各种不同的使用方式。我区分了两种主要的验收标准类型:规定性的和指导性的。

让我们深入了解你如何使用它们来构建更好的产品。

跳到前面去

  • 规定性的验收标准
  • 规定性验收标准的例子
  • 规定性验收标准的目的
    • 管理预期
    • 管理范围
    • 作为估算的基础
    • 作为测试计划的输入
  • 指导性验收标准
  • 指导性验收标准的例子
  • 结合指导性和规范性验收标准
  • 验收标准与 “完成 “的定义

规定性的验收标准

当有人提到验收标准时,他们通常是指规定性的验收标准。

你可以把它们想成两点:

  • 他们作为一个详细的需求列表
  • 你可以把它们作为用户故事,分解成更小的片段

prescriptive-criteria

规定性验收标准的例子

让我们来看看规范性验收标准的一个例子。

故事: 转移溢价点

验收标准:

  • 在主页上有一个主要的CTA按钮,上面写着转让积分。
  • 当用户点击该按钮时,他们会看到一个积分转移的模式,其中包括:
    • 一个朋友下拉列表(必须)。
    • 一个添加朋友的按钮。
    • 一个点数的字段(强制性的)
    • 一个发送按钮
    • 一个取消按钮
  • 用户从一个下拉列表中选择一个朋友
  • 用户可以在该字段中输入100至1000分
  • 如果他们没有足够的积分,显示一个错误的模式
  • 如果他们输入的点数太少或太多,则显示一个错误模式
  • 当他们点击发送时,验证所有字段是否正确
    • 如果不是,抛出一个标准的验证错误
    • 如果是,显示另一个你确定吗?
    • 点击 “是 “就完成了转移。
      • 点击 “否”,用户将回到积分转移模型。
    • 完成转账后,将交易添加到发送方和接收方的历史记录中,标题为:积分转账: 从{用户身份}到{用户身份}的{金额}。

规定性验收标准的目的

在你的产品开发工作中使用验收标准有很多原因。最常见的原因包括:

  • 管理预期
  • 管理范围
  • 作为估算的基础

管理预期

验收标准有助于管理PM和产品团队以及团队和利益相关者之间的期望。

它们精确地定义了一个特定的功能将如何工作。如果你的 “我想登录 “的用户故事在验收标准中有一个 “用Google登录 “的选项,这就建立了明确的预期,即用户能够用Google登录,但不一定能用Facebook登录。

好的验收标准不会留下任何误解的空间。

管理范围

谁从来没有为满足最后期限而削减过范围?扔一块石头吧。

验收标准可以帮助项目管理人员确定活动的范围,无论是在增加还是删除计划的范围方面。毕竟,你可能无法删除 “我想登录 “这个用户故事,但你可以把它从花哨的验收标准中剥离出来,留下基本的东西。

验收标准可以帮助你以更细微的、手术刀式的精度来管理范围。

作为估算的基础

估算对象越模糊,估算就越模糊。验收标准提供了非常需要的细节,使开发估算更加精确。毕竟,我们可以花一个小时或一个星期来处理 “我想登录 “的故事,这取决于登录过程的具体细节。

作为测试计划的输入

在准备测试用例时,验收标准是对QA团队的宝贵输入。有了正确编写的验收标准,他们就能确切地知道要测试什么,以及某个功能应该如何工作。否则,他们可能需要一直问团队,”这是一个错误还是一个功能?”的问题。

指导性的接受标准

在产品团队成熟度的某个层面上,对解决方案的详细描述不仅是不必要的,而且往往是非常有局限性的。

在这种情况下,以高层次的一般目标的形式来写验收标准可能是比较明智的。

这都是为了给团队一个高层次的方向,让他们自己去想其他的事情。

指导性验收标准的例子

故事: 转让保费积分

验收标准:

  • 用户应该能够将最多1000个积分转移到朋友的账户中。
  • 这个过程应该是简单和用户体验友好的
  • 不要过度复杂化。让我们尝试在一个冲刺阶段做出一个MVP。
  • 包括防止意外的积分转移的机制
  • 记录和存储所有的转移

这样的描述给出了足够的细节,为倡议提供了边界,同时也给了团队定义具体细节的所有权。最后,产品团队最有资格决定实际的解决方案,产品经理应该尽我们所能授权他们这样做。

结合指导性和规定性的验收标准

不同类型的验收标准对产品团队有不同的用途。

指导性的验收标准作为一种高层次的边界形式效果很好。把问题带给团队,让他们发现潜在的解决方案,一旦你决定了一个方向,就根据业务需求和约束为解决方案设定边界。

然后,当团队确定解决方案的细节时(有时与产品经理协商,有时自主),让他们写出更详细的、规定性的验收标准,以帮助他们管理期望和范围。

combining-criteria

归根结底,这不是指导性或规定性的验收标准。两者在解决方案开发的不同阶段有不同的目的。

验收标准与已完成的定义

常见的困惑之一是验收标准和完成的定义之间的区别。

虽然它们的目的相似,但有一个很大的区别。完成的定义是由所有的用户故事共享的,而验收标准是针对故事的。

完成的定义是由所有用户故事共享的,而验收标准是针对故事的。

user-story-vs-acceptance-criteria-vs-definition-done

另外,验收标准通常作为开发检查表,而完成的定义则作为整体过程检查表。

换句话说,验收标准包括那些应该作为功能的一部分来构建的东西,比如 “用Google登录 “和 “给我发邮件发送神奇链接 “的功能。

同时,”完成 “的定义描述了用户故事的整个过程(如开发、测试、编写文档、进行压力测试,以及任何属于 “完成 “定义的部分)。

只有当验收标准和完成定义都得到满足时,故事才算完全完成。

总结

有两种类型的验收标准。

指导性验收标准是产品团队的高级方向和界限。规定性的验收标准作为一个更详细的检查表,帮助管理预期和范围,估计票据,并计划测试案例。

不太成熟的团队通常会收到带有预定义接受标准的需求。但是,一旦团队成熟了,他们就会根据他们要解决的问题和高水平的指导性验收标准来写自己的验收标准。

尽管验收标准在概念上与 “完成 “的定义相似,但前者与特定故事的形状有关,后者定义了每个用户故事作为开发过程的一部分应该经历的旅程。

翻译:云瑞设计

原文:logrocket

云瑞设计小程序
云瑞设计小程序

微信扫一扫
手机使用更方便!

云瑞设计订阅号
云瑞设计订阅号

关注我们的微信订阅号,不错过任何福利。