在out项目中，用户故事的工作流程为ToDo-进行中-Dev-SIT-UAT 现在我们面临的挑战是计算速度 因为考虑到开发，SIT和UAT测试中涉及的工作，我们给了遗憾。但是在网站上是sprint，我们只能将用户故事推送到开发人员，而不能在sprint中完成SIT和UAT。 现在计算速度的正确方法是什么？
答案 0 :(得分：2)
速度是衡量团队在工作中可以完成的工作量的量度 单个Sprint，是Scrum中的关键指标。速度计算 在Sprint的末尾，将所有全部的积分总计 完成用户故事。
由于您没有完成故事，您的速度为零。如果您保留项目进度，则在完成SIT / UAT时可能会看到一些积分。这可以使您了解完成了多少工作以及何时完成项目。
开发团队由从事以下工作的专业人员组成： 在网站上交付可能发布的“ 完成”产品增量 每个Sprint结束
猜想您需要弄清楚如何在Sprint中完成工作DoneDone。这个想法是要真正完成Sprint中的工作，这可能是一个挑战，但是请尝试重新组织工作以实现它。
如果一旦完成一个故事，您再也不必这样做，那会不会很好 回来吗？这就是“完成”背后的想法。一个完整的故事 不是一大堆未经集成，未经测试的代码。准备部署。
在下一个retrospective中，我将花费一些时间，并讨论如何在Sprint中完成故事。怎么办
在开始下一个故事之前，我建议Swarming一个用户故事并DoneDone进行讲故事。
注意障碍，并加以解决以加快交付速度：
答案 1 :(得分：-1)
我的建议是，在给定的时间段（天，周，月等）内，测量从工作流程开始到工作流程结束的故事点数量，这将使您的团队在故事点上的速度变快。
答案 2 :(得分：-1)
如果：
集成测试是完全自动化的
如果没有，那么您的团队中就有一名测试人员，他会在故事部署到SIT服务器上后立即进行测试（由持续交付工具（如詹金斯）自动部署）
开发人员说“看一看”（甚至可以在笔记本电脑上完成）后，就会有人接受这个故事。
产品所有者是接受故事的人
在Sprint评论（“演示”）中，向用户显示新的Produxt增量并请求反馈
...然后，您将获得流畅的状态，并且只有三种状态：待办事项-正在执行-完成。发布/部署到生产只是冲刺中的另一个故事。
...然后Jira会告诉您您的速度，您可以在Jira中使用所有其他非常有用的报告：-）
...，团队中的每个人都很高兴，因为人流多。而且功能可以快速交付给最终用户。