最适合敏捷方法的项目是那些有着激进的时间期限限制，那些有着高度的复杂程度，以及那些有着高度新颖性(独特性)的项目。当我们在做一些新的事情，到少是对于开发团队是新的事情，我们会比较愿意使用敏捷方法。
如果这是一件团队以前曾经重复做过很多次的事情，他们很可能就不需要用敏捷的方法来做了。对我来来说，这种时候就应该考虑引入类比制造的方法了。如果我们每天建造同一种车，我们很快就会了解到造车中的每一个细微差别。我们不需要一个敏捷的方法因为在这种情况下新颖性非常低。
但是单独的新颖性本身并不一定就意味着必须使用敏捷流程。我今天去了我最喜欢的一家中国餐厅吃午餐。我点了一道“三倍辣外加墨西哥胡椒”的主菜。这也许是他们第一次这样做这道菜，而且这是一个少见的或者独一无二的点餐。但是厨师做得非常好。而且我确定(因为我能看到厨房里面)他们不需要站会或者测试驱动的方法来做这个午餐(然而，我好像看到他们背后有一个看板，所以说除了新颖性，使用敏捷的项目也需要有一定程度的复杂性。
一个我认为在决定一个项目是否适合于使用敏捷方法的最终因素是紧急性。敏捷方法中的时间箱和迭代就是为了保持项目中的紧张度和专注度。如果项目没有紧急性，这些就是不需要的。让我们一起看一下这三个因素-紧急性，复杂性和新颖性-在不同的项目中是如何组合的。当然，从软件项目开始来看。没有比软件项目更适合的了。软件项目是出了名的复杂。每一个新的软件项目中的大部分内容都是新的尝试。而且在当今社会，软件项目总是很急的。
但是让我们再看看另一个我们大家都听过的适用于Scrum的情形：婚礼筹备。我每年至少有好几次听说人们用Scrum方法来筹备婚礼。人们会准备一份婚礼的backlog–买蛋糕, 找摄影师, 发邀请, 准备服装等等. 那么筹备婚礼与我所说的三个因素什么关系呢?紧急性?看一看。总是有一个限期在那里而且通常是不能改的。
敏捷特别适合于那些很紧急并且非常复杂及比较新颖的项目，可以是软件项目，也可以是婚礼。夫妇俩是否要在庆典的结尾有第一个吻，这是否应该属于backlog的一部分，还是应该算产品完成标准的一部分，这样的问题是必须要搞清楚的。
它与软件项目不太一样但是有它自的复杂度，通常由非功能性的需求带来，比如固定的预算，谁应该坐谁的旁边，提供什么类型的食物，是否要让艾拉表妹乐队做迎宾演出等等。新颖性，是的。大部分人都不会有太多次举办这种大型庆典活动，所以筹备活动对他们都是有很强的新颖性的。