，使得一些重要的事情会被抛之于脑后，而一些难度小确信能够完成的事情会被当作重要事项看待，从而导致重要的、紧急的事情没有做，而不紧急的事情却很好的被完成了，形成本末倒置的现象。
3.抛开KPI、3-5件事的评价体系的有效性不说，KPI与3-5件事带来的管理成本也很高的。尤其在我们公司实现季度KPI+月度3-5件事的考核模式，则更加重了管理负担。假定某个月份既要做KPI考核又得做3-5件事考核，我们以一个35名员工的部门管理者来说：在月初，首先需要制定35份员工的KPI计划，并与员工达成共识，我们以每份30分钟计算，将消耗管理时长30*35=1050分钟;然后再制定35份员工3-5件事，也以每份30分钟计算又将消耗管理时长30*35=1050分钟;在月末，先针对3-5件事，进行数据采集，评判，消耗管理时长30*35=1050分钟;然后，对每个员工季度的KPI进行数据采集、评估、沟通，每份以50分钟计算将消耗管理时长50*35=1750分钟。这样四项时间累计为1050+1050+1050+1750=4900分钟，以每个工作日扎实工作7小时计算为11.7工作日。上述时间还不包括部门的KPI、月度3-5件事制定。一个月22天的工作日，将有一大半时间耗费在这样的考核上去，必然对日常的管理造成极大的冲击，而一些真正需要管理、把控的东西，如需求分析、迭代会议、迭代演示、冲突解决、架构设计、组织协调等丢弃一边了。
我们仔细地分析上述问题，可以得出一个上述KPI+3-5件事考核存在的弊端的根源，人为的定义一些难以评判员工的指标或者任务，并导致管理成本的增加。那么是否可以寻找到一条在现成研发体系中存在的可度量手段并以此为依据进行员工评价的路径，成为解决问题的关键。
我们知道在敏捷开发SCRUM模式下，需要准备任务的backlog并在迭代启动前把任务分解成一个一个不可再分的子任务，然后由开发人员评估每项子任务的工作量，并把任务分配到开发人员手中。在上述过程中，客观的进行了工作任务的分解和工作任务的度量，而历史的团队绩效数据则成为进度估算的依据，尤为重要的是这些度量是被接受并被承诺的。而“建立估算”、“开发项目计划”和“获得项目承诺”是CMMI中"Project Planning"域的三个特定目标。与3-5件事中的任务制定和分解比较，这里的数据没有经过人为修饰，是客观实际情况的真实反映;而且这些任务分解不是为了考核而考核，而是为了项目推进而进行的，并没有额外的增加管理工作;更重要的一点是，除了完成与否之外，还有具体每项子任务所需要的工作量(估算点)，可以方便的度量项目每个人员付出的劳动量的多少。因而在SCRUM模式下，3-5件事是简单的、不完整的、多余的。
绩效考核最终的目的是为了能够客观的反应人员在工作上的投入度、获得的成果，从而识别出优秀者与糟糕者。3-5件事是绩效考核的一个补充手段，并非全部，我们往往还有每年或者每季度的一系列KPI指标。就像前面所说的一样，针对研发人员而言，这些指标往往不具有有效性，因为缺乏有效的度量手段。可是在SCRUM模式下，对于工作量的度量却能够做得非常容易了，因为我们可以轻易的获取到每个开发人员所完成的故事点(工作量)。
因而，在SCRUM模式下，无需额外的进行3-5件事，管理者可直接关注到每个项目的完成情况。在进行绩效评价时，可以方便的获取到工作量数据，有效解决KPI指标失灵问题。
上面的结论，让人很轻松，我们找到了一个有效的绩效考核方法。不过，上述方法还存在一定的瑕疵：在SCRUM模式中，度量更多的是针对开发人员，缺乏对测试、需求、实施人员的有效度量，虽然开发人员占了研发50%以上的人员比重，但毕竟他们不是全部。