【问题标题】:How to NOT use story point in Azure Devops如何在 Azure Devops 中不使用故事点
【发布时间】:2020-08-20 19:05:41
【问题描述】:

我完全理解什么是故事点以及它们的优势和不便,但我正在努力激励团队迁移到 Azure DevOps,目前我们不使用故事点(而是整个团队进行的估算)。我知道这并不理想,但这不是重点。

我想知道是否可以将 Azure Devops 配置为不使用故事点但需要努力?

谢谢!

【问题讨论】:

  • 似乎您想为您的项目使用“Scrum”模板而不是“Agile”模板。 “Scrum”模板具有“产品待办事项”而不是“故事”。它还使用努力而不是故事点。您是否有理由卡在“敏捷”模板上?
  • 我发现命名法更清晰,但不,没有具体原因,我必须选择一个。

标签: azure-devops


【解决方案1】:

正如 Matt 在评论中指出的那样,您可以选择使用 Scrum 工作流程 而不是敏捷工作流程

努力用于产品待办事项(在 Scrum 模板中),故事点用于用户故事(在敏捷模板中)。

努力

估计使用任何单元完成 PBI 所需的工作量 您的团队喜欢的衡量标准,例如故事点或时间。一种 数值是必需的。

Scrum 团队完成产品待办事项项目估算后,他们就会继续将每个 PBI 分解为任务。然后他们对任务进行基于时间的估计(例如,任务 1 = 2 小时)。

更多详细信息和流程您可以参考我们的官方文档--Scrum process work item types and workflow


更新:

它由工作日和每天的容量控制,您可以简单地参考下面的示例截图。

【讨论】:

  • 好的,一旦任务执行完毕,如何根据团队的能力用刚好足够的工作量来填充迭代?
  • 这可能是一个单独的问题,但这个答案可能主要涵盖了您正在寻找的内容:stackoverflow.com/questions/63304611/…
  • @J4N 同意马特的观点。使用capacity bars 做出这些决定:1。如果您的团队超出或低于容量,请调整您的 sprint 计划 2.在您的团队中平衡工作 3.快速将任务重新分配给其他团队成员 此外,您也可以在这里查看其他人的建议和经验:What should we do if there are not enough PBIs to fill a final Sprint in Scrum?
  • @PatrickLu-MSFT 这些容量条的依据是什么?我做了一个小测试,每周只有我几个小时可用,但即使我添加了指定“努力”的任务,条形图仍保持在 0/9h。
  • @PatrickLu-MSFT 您不能只估算产品积压项目吗?我看到它考虑了对子任务的估计,但我们经常有足够小的产品积压项目。还有如何在查看 sprint 利用率的同时向 sprint 添加作业?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-03-10
  • 2020-06-25
  • 2022-07-20
  • 2020-02-03
  • 1970-01-01
  • 2020-09-22
  • 1970-01-01
相关资源
最近更新 更多