下面这张图能简单说明敏捷的人员组成以及一些基本实践。
需要完成的工作：产品代办列表（Product Backlog）、冲刺代办列表（Sprint Backlog）、工作项分解。
通常通过“用户故事”的方式来表示产品代办列表、冲刺代办列表，产品代办列表的用户故事可能比较大，需要进一步细分为比较细的用户故事，然后放入不同的Sprint中，作为不同Sprint的代办事项，而Sprint中的用户故事，还可以继续拆分成更细的工作项分解。
这些需要完成的工作，需要通过大小迭代来完成。
大迭代是指：Sprint（冲刺，也就是小版本），通常是30天的时间，每30天增量式的交付“可运行的软件”。“可运行的软件”这个说法还不太好，应该是“可工作的软件”，否则你可能认为编译通过程序能跑就是“可运行”了，而“可工作”才是重要指标，不仅仅能运行，还能为客户带来实在价值，才叫“可工作”。
小迭代是指：每天的项目会议，通常是15分钟内。开会时间可以是早上、中午或下班前。形式和时间都不是关键，关键是要有效，要领会24小时开一次会议的核心思路！我们都知道问题越早发现越早处理，处理成本越低，24小时开会让问题被发现时间不会超过24小时，将问题消灭萌杀状态，同时每天修正项目的方向，保证我们一直在做正确的事情。
需求方面最佳实践：
1）User Story（客户故事）
2）客户全程参与
测试方面最佳实践：
1）测试驱动开发（TDD）
2）自动化测试
编码方面最佳实践：
1）结对编程
2）持续集成（每日构建）
项目管理方面最佳实践：
1）Sprint（冲刺）、小版本发布
2）每日站立会议、每日晨会
3）每周工作40小时
4）Burn Down Chart（燃尽图）
