通常是每天工作开始时召开的简短例会，整个团队成员均需参加并简要回答3个问题：你昨天做了什么，你今天计划做什么，以及，你是否遇到什么障碍。每日站立会议对沟通交流和尽早发现问题很重要，绝大多数敏捷方法论都将会议时长严格限制在15分钟。

敏捷的实践方法，尤其体现在精益中，意思是只要有责任保留所有可能的途径就尽量推迟决策、同时基于尽可能多的已知情况做决策。

描述产品未完成项理想属性的缩略语，含义是：详略适宜的（Detailed Appropriately）、可估计的（Estimatable）、涌现式的（Emergent）、排好优先级的（Prioritized）。

“不要重复你自己（Don t Repeat Yourself）”的缩写。DRY强调了要最大限度去做尚未完成的工作。例如，“这个模块不太DRY”就表示代码与已完成部分有重复，需要重写，不能直接利用该模块。

敏捷团队的必要属性。在敏捷项目中，授权的概念是指团队能够做出必要的决定来增加交付价值。传统项目则相反，典型做法是必须征得上级同意才能做决定，或者多数情况下上报，由上级来做决定。

Task任务

也成为工程任务，是对工作一种较小的划分，由单人承接，而且通常能迅速完成。任务是比用户故事更小的一种划分，而且不像用户故事，任务可能会交付价值给用户，也可能不会。

产品由团队交付给客户后由客户报告发现的缺陷。漏网缺陷数量的激增很可能表明团队存在流程方面的问题。

适用于全体团队成员的不成文规定，应该与团队中每位成员进行沟通。举例：无需逐个询问，可以预期团队中的每位成员早上8点会集合召开每日站立会议就是一项基本规则。

面对面的沟通，称之为高带宽是因为很多信息通过肢体语言、身体语言、面部表情和语音语调来传送。高贷款沟通是首选的项目沟通方式。

指如果没有什么事干扰或引起分心的话，完成一项任务所需耗费的时长。一些敏捷项目使用理想时长而非实际时长来进行估算。

敏捷的理念，指产品应该分成一个个小小功能陆续交付给用户，而不是等到所有功能全部开发完毕整理交付给客户，这样客户在产品演进过程中就能及时施加影响，且随着产品开发而不断学习，并最终收益。

团队与其他干系人之间用来沟通项目状态的一组组件。信息发射源对保持团队工作进展的透明度及能见度很重要。

描述一个好的用户故事理想属性的缩略语，代表了独立的（Independent）、可协商的（Negotiable）、对用户或客户有价值的（Valuable）、可估计的（Estimatable）、短小的（small）、以及可测试的（Testable）。

敏捷项目中重复的工作循环。迭代通常包含一个简短的计划会议，然后是一个时期的工作，最后是回顾会议，评估流程和结果并作相应调整。

几个迭代可以组合形成一个版本发布，同时迭代可以在项目过程中重复多次。敏捷原则指出迭代周期持续时间从2周到2个月不等，而极限编程方法论则把迭代周期压缩到1周。

基于以下7项原则的一种敏捷方法论：消除浪费，强化学习，尽可能晚决策，尽可能尽快交付，授权团队，构建完整性和全盘检视。精益寻求最大化过程中工作（WIP）的可视性，是一种高度自律的方法论。