六问：用什么来判断软件团队在真正实施Scrum?
六答：对这一问题，Scrum创始人之一Jeff Sutherland用诺基亚测试的8个判断条件来判定是否在真正执行Scrum。这8个判断条件是：
1 你们有固定的迭代周期么？你们的迭代周期是否以某个特定的时间开始并以某个固定的时间结束，且迭代周期必须少于6周？（回答否定的则不符合迭代开发原则）
2 在每个迭代周期结束时，你们能提供可以工作的软件么？（回答否定的则不符合迭代开发原则）
3 在迭代开始之前，你们是否需要必须有一个完整细致的需求说明？（回答肯定的则不符合迭代开发原则）
4 是否将测试作为迭代增量开发的一部分，在开发过程中进行测试？（回答否定的则不符合迭代开发原则）
接下来，用4个附加的Scrum规则来判断是否实现了Scrum：
1 你们是否有产品所有者？是不是有人可以代表客户和你们一起工作？
2 如果有产品所有者的话，他们是否能提供待开发的产品Backlog？且此产品Backlog是否按照优先级来排序的？是否估算过开发这些功能的所需时间？
3 团队在开发过程中是否使用了Burndown图来展示工作量变化、跟踪进度、推算团队开发速度？
4 在迭代过程中，是否能保证项目经理不干涉团队工作？
通过以上8点基本上就可以确定，团队是否真正地实现了Scrum。
七问：在Scrum中我怎样去度量团队绩效？
七答：你可以通过速度去度量团队绩效，即在一个Sprint中将需求转化为软件功能的能力。可以是一个Sprint中完成多少Product Backlog Item（包括功能和非功能需求及其他议题），或者转化为1个合适单位货币如10000完成多少Product Backlog Item。
八问：在Scrum中我怎样去度量个人绩效？
八答：你不能度量个人绩效，只能度量整个Scrum团队的绩效。Scrum是自我管理的团队，而不是个人组成的组。当然，可能你的软件组织要求这么做，这确实是个棘手的问题，我也没有好的解决方案。对于软件组织这一层面，我建议你首先把度量的焦点聚焦于你生产的软件、真正的开发功能和软件组织用于改进基准和市场价值的能力。而项目这一级别，我建议将完整的个人检查过程简化为3个问题：你对增加组织的价值有什么帮助？你做了什么使客户高兴？你的同事怎么看待你？可以请同事来评估个人贡献，并列出1～10的等级。在Daily Scrum Meeting上，你可以看到谁有贡献，谁没有。
九问：在Sprint期间，如何去修改一个缺陷？
九答：Scrum团队的目标之一是在发现缺陷的Sprint中就修复它们。在他们逐渐精通采用30天迭代周期以后，尤其是通过对自动化测试的利用，他们能够达到这个目标。当Scrumt团队成员做出对某项编码任务的估计时，这个估计值就包含了用于修复在实现过程中发现的缺陷的时间，否则就应该确定和估计一个独立的任务（“修复缺陷”）即缺陷作为Product Backlog Item处理。我的偏好是只确定一项任务，但是在它通过所有的测试之前不认为已经完成。
后来发现的（或者在发现它的迭代中没有修复 的）缺陷应该按照与Product Backlog一样的方法来对待。应该按照与Product Backlog一样的方法确定缺陷修复工作的优先级，分配到后续的某次迭代中。只要超出一次迭代的范围，就不再有什么缺陷的概念。修复一个缺陷和增加一个功能只是一件事的两种说法。另外，如果现有团队还需要维护现有产品时，则需要提醒软件团队在做计划时拿出专门的时间处理那种需要马上响应的缺陷修改任务。
十问：Scrum的局限性是什么，实施中需要注意什么？
十答：我们都知道Scrum只是一种敏捷管理的一种实践框架（Framework），任何方法都有其边界和局限性，套用业界流行的一个说法就是“没有银弹”。Scrum为软件开发管理只定义了一个高层次的、易于操作与遵循的非常小的实践集，Scrum避免了说软件团队应该如何开发软件，它坚持认为：人们在自己的工作中和处理问题时，应该像一个成熟的成年人一样，因此它并不涉及具体的软件开发技术和人员沟通、期望管理、问题冲突等管理技能，这些都需要其他相关理论和技能来补充，另外，如同其他项目一样，需要软件团队在其业务领域的专业能力来确保软件项目的成功。
Scrum源于美国软件界，对国内实施强调自组织管理的Scrum需要破除可能习惯于听命行事的组织环境，建立自我约束、自我组织和实现的工作管理方式和组织环境，同时根据Scrum背后的科学原理则可以根据特定的情形进行调整。建议最初时，按Scrum提供的实践框架执行，然后，当积累了丰富实践经验后再根据Scrum提供的避免做什么的说明视实际情形进行调整，到最后，不要在乎自己是否执行Scrum或是其他什么敏捷方法，也就是达到从心所欲不逾矩。
