，尽管这些变更可能会给项目计划和项目进度带来麻烦，但这种观念上的转变更能体现开发团队和客户之间合作的诚意。
客户在迭代周期中的变更大致可以分为五种类型：添加新需求、删除本次迭代周期内的需求、删除之前迭代周期内的需求、更改本次迭代周期内的需求、更改之前迭代周期内的需求。这就是说，开发团队需要实时高效地管理这些变更，并且将需求变更涉及到的迭代周期内项目计划和人员安排变更的影响最小化。
3、需求、测试用例、Bug管理脱节
我们希望在需求、测试用例和Bug之间建立一种动态的联系，能够实时地更新三者的状态，并且实现三者之间状态的动态联动，从而减少开发团队在管理和维护需求、测试用例和Bug时的工作量。
软件开发中，需求和测试用例是紧密联系的，通常来说，一条需求只有通过了所有针对该需求的测试之后才能说这条需求的实现真正实现了。需求的变更直接影响到与该需求相关的测试用例的更新，继而影响到现有Bug的状态的更新。然而现实情况却是，大多数敏捷开发团队都没有实现需求、测试用例和Bug的一体化管理。测试的结果是产生Bug报告，如果针对某条需求的一个测试用例没有通过测试，换句话说，也就是产生了一个Bug，这就说明该需求根本没有完成。
4、缺乏有针对性的需求管理流程
为了弥补需求变更对项目进程带来的影响，开发人员常常需要快速的进行功能修改和增加，而没有遵循统一的流程控制，从而常常使得软件开发的有序性被破坏，人为地增加了工作量。这就需要有更为高效和精简的需求管理过程以及相应的工具支持。传统的需求管理过程，尤其是其中的变更控制过程是针对那些组织机构清晰，只能定义明确的传统软件项目，其流程相对比较严谨和死板。