敏捷开发中如何定义“完成”是指某一项开发任务认为在完成冲刺后，敏捷任务即可视为完成。冲刺通常是项目过程中持续时间较短的任务，通常为一天、几天，但最长不会超过一个月。冲刺完成之后，团队开会并回顾已完成的工作、需要调整的地方和未来的行动规划。计划依然存在，但已经被调整以符合实际工作情况；
完成迭代
理论上，每完成一次迭代就意味着项目的完结。但事实并非总是如此。一旦出现了必须解决的问题，项目就必须快速对这些变更做出响应。因此，我们不建议在每个冲刺（sprint）后发布产品。但需要确保在sprint阶段完成各个功能，以便追踪项目的进度。
因此，完成工作意味着产品的各项功能得到充分地开发、测试、设计并得到产品负责人的认可。只有这样才可算完成。敏捷中有很多“完成”，但如果有任何存疑之处，sprint就没有真正完成，因此也不应交付。
在产品真正完成和交付之前，每个功能是否完工都需要取决于其他功能的完成情况。这就意味着需要整体的完成。但每个sprint都应该在结束是完成某个特定功能。这就意味着如有必要，该功能在sprint结束时可以单独交付。
团队差异
但每个团队都有自己专属的完成定义，这从另一方面说明所有的用户故事标准已经得到认可。但无论这个定义是什么，它要能提高工作质量，并在用户故事完成时进行评估。
在软件开发方面，完成指的是某些内容按照标准进行了编码，经过了审查、实施、测试、整合和记录。在服务支持方面，指的是用户故事的每个任务都已经完成，产品所有者对其进行了审核，并确定所交付产品满足了需求。
在敏捷中，完成意味着团队知道需要交付什么，并且按要求进行了交付。完成是一种确保透明的手段，能够确保工作的质量符合产品要求和组织目的。
完成的定义是否会变化？
敏捷这种至关重要的管理方法可以在各类框架中执行，包括 Scrum、极限编程、自适应软件开发、DSDM、特性驱动开发、看板和水晶方法等。
这些流程是可在敏捷框架内工作的方法，但它们具备不同的方法和功能，可以适用于不同类型的项目并发挥最佳的成效。具体哪一种更好可能需要取决于具体项目的情况。但这并不意味着每个项目只能选择一种方法。综合运用一个或多个方法，可能更适合项目的需求。敏捷之所以广受欢迎，也恰好是因为其灵活性及过程的多样性。尽管敏捷包含不同类型的进程，它们都遵循了同样的完成定义。
(图为Scrum敏捷开发流程)
完成的原则是不变的
2001年发布的《敏捷宣言》宣告了敏捷的诞生。宣言的发表是为了回应传统的软件开发管理方法，它概述了每个敏捷框架中存在的基本概念。敏捷宣言强调的四个核心价值是：
个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划敏捷软件开发还提出了12条原则。这些原则充分体现了我们对任务或项目何时真正完成的理解：
敏捷从不仅是作为IT项目管理的工具，它还可以改变其他企业的管理流程，使用敏捷思想来改变管理项目就是一个非常好的例子。
敏捷某些方面的特征，如待办事项等，可以在企业项目中使用并将成为最终交付项目的部分功能和特征。项目中的冲刺或短期项目，能充分发挥敏捷的快速和高适应性优势。敏捷的另外一种应用是跨职能团队的构建，这能大大提高沟通效率。且持续集成还将有助于提高项目不同版块之间的透明度，从而提高工作效率。此外，还有信息发射源、迭代、增量开发、Scrum会议、时间盒、用例、用户故事等等，所有这些都能够帮助公司用与传统瀑布开发不同的方法完成工作。
为了获得在敏捷环境中工作所需的透明度和协作，我们需要运用正确的工具，确保每个人都知道完成的定义。
