在项目中，用户故事的工作流程是 待办事项 - 进行中 - 开发中 - SIT - UAT 现在我们面临的挑战是计算速度 因为考虑到开发，SIT，UAT测试所涉及的努力，我们给予遗憾。但是在网站上是冲刺，我们只能将我们的用户故事推送到开发，而无法在冲刺中完成SIT和UAT。 现在计算速度的正确方法是什么？
速度是衡量团队在 单个Sprint，是Scrum中的关键指标。计算速度 在冲刺结束时，通过完全汇总所有积分已完成的用户故事。
https://www.scruminc.com/velocity/
由于您没有完成故事，因此您的速度为零。如果您保持项目燃尽，您可以在完成 SIT/UAT 时看到一些获得的积分。这可以让您了解完成了多少工作以及项目何时完成。
开发团队由从事以下工作的专业人员组成 在每个冲刺结束
https://www.scrumguides.org/scrum-guide.html#team-dev
猜猜你需要弄清楚如何在Sprint中完成你的工作。这个想法是在Sprint中真正完成工作，这可能是一个挑战，但尝试重新组织你的工作来实现它。
如果一旦你完成了一个故事，你就不必这样做，那不是很好吗？ 回来吧？这就是"完成完成"背后的理念。一个完整的故事 不是一堆未集成、未经测试的代码。它已准备好部署。
https://www.jamesshore.com/Agile-Book/done_done.html
在下一次回顾中，我会花一些时间讨论如何在Sprint中完成故事。需要什么？
我建议在开始下一个之前，先蜂拥而至，然后完成单个用户故事。
注意障碍并修复它们以更快地交付：
- 如果在冲刺期间无法执行系统集成测试，请投入时间使其更容易部署到测试/过渡系统。
- 安排定期与用户待办用户验收测试的时间，或邀请他们参加Sprint评审，让他们玩一玩。为他们发现的事物创建新故事。
- 尝试拆分故事以使它们更小，以便更容易真正完成。
我的建议是测量在给定时间段(天、周、月等(内从工作流开始到工作流结束的故事点数量，这将为您提供团队在故事点中的速度。
如果：
-
集成测试是完全自动化的
-
如果没有，您的团队中有一名全职测试人员，一旦故事部署到 SIT 服务器上，他就会进行测试(通过 Jenkins 等持续交付工具自动部署(
-
一旦开发人员说"看看它"(甚至可以在笔记本电脑上完成(，就会有人接受一个故事。
-
产品所有者是接受故事的人
-
在Sprint评审("演示"(中，向用户展示新的Produxt增量并请求反馈
。然后你得到流，你只有三种状态：待办事项 - 正在做 - 完成。发布/部署到生产环境只是冲刺中的另一个故事。
。然后 Jira 会告诉您您的速度，您可以在 Jira 中使用所有其他非常有用的报告：-(
。团队中的每个人都很高兴，因为有心流。功能可快速交付给最终用户。