Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Read this interesting article on Scrum Alliance about individual team performance appraisals in Scrum teams and how they are antithetical to the process and spirit of Scrum. As the author Nanda Vivek states:
The fundamental point is that if a Scrum team member is not able to contribute, then this points to a team problem. The Scrum spirit means that everyone jumps in to help; ideally, all team members work together on all of the stories. Different skill levels or types contribute to the best of their abilities. To create metrics for individuals, besides being inaccurate, would probably cause competition and division within the team. Individuals should work as a unit, be tracked as a unit, and succeed or fail as a unit...
My conclusion is that tracking an individual's performance constitutes crime in the Scrum world. The fundamental idea of Scrum is team collaboration, and team members "volunteer" for tasks rather than having them assigned. One of the core values of Scrum is courage, and it's not a bad practice to announce at the daily stand-up, "I missed my task timeline today." If that's the case, the Scrum team collaboratively aligns itself to meet the sprint backlog, at least enough to result in a shippable product when the sprint ends. It's certainly possible that not all tasks in the sprint backlog get completed at the end of the sprint, but the Scrum team should be smart enough to plan the next sprint in a way that avoids a similar pitfall.
I think this notion rest on a flawed assumption that because Scrum teams are self-organizing, that the teams would by default, just "volunteer" for tasks on a backlog item. During the initial planning process, a review of the requirements, backlog items, story boards, etc. will allow the ScrumMaster and team leads to determine what resources and skillets need to be identified to complete the working deliverables at each iteration. This would be no different than in traditional project management where resources need to be identified, assigned and allocated for a project.
In addition and especially if you’re running Scrum in a large organization, these resources will be working on other projects that you must weigh against your own to get a realistic sense of when your project can be delivered based on the priority of your project weighed against others. The reality is that often times you have to "borrow" these resources to complete your project both in Scrum and traditional projects.
Furthermore, as well as self-organizing is the idea that teams would be cross-functional in Scrum wouldn't negate the need for a subject matter expert in Java development, QA tester, UI design, etc. to be identified. If an XP process is used so that you pair people of different skill sets to work with each other, these other SMEs should acquire enough skills to pick up the slack when the core team SME is not available or too busy to get their deliverables done on time. But this takes time to build this maturity and would still require you to identify, acquire and assign these resources to a Scrum project before you can get to the point where teams start to self volunteer and organize. If team members leave, this process starts over again.
In these situations, the Agile retrospective becomes important to evaluate a team’s performance as well as understanding an individual team member's contribution to both the velocity and completeness of their contribution to the deliverables of each iteration. This historical data is important to have to anticipate the success of upcoming Scrum projects. A company's financial stake is on the line for the success of the delivery of Scrum projects and whether we like to acknowledge it or not, individuals in a team are paid to deliver on these projects and the only way to accurately and fairly gauge this is by analyzing in depth their performance and contribution to the project.
I think this notion rest on a flawed assumption that because Scrum teams are self-organizing, that the teams would by default, just "volunteer" for tasks on a backlog item. During the initial planning process, a review of the requirements, backlog items, story boards, etc. will allow the ScrumMaster and team leads to determine what resources and skill sets need to be identified to complete the working deliverables at each iteration. This would be no different than in traditional project management where resources need to be identified, assigned and allocated for a project.
In addition and especially if you’re running Scrum in a large organization, these resources will be working on other projects that you must weigh against your own to get a realistic sense of when your project can be delivered based on the priority of your project weighed against others. The reality is that often times you have to "borrow" these resources to complete your project both in Scrum and traditional projects.
Furthermore, as well as self-organizing is the idea that teams would be cross-functional in Scrum wouldn't negate the need for a subject matter expert in Java development, QA tester, UI design, etc. to be identified. If an XP process is used so that you pair people of different skill sets to work with each other, these other SMEs should acquire enough skills to pick up the slack when the core team SME is not available or too busy to get their deliverables done on time. But this takes time to build this maturity and would still require you to identify, acquire and assign these resources to a Scrum project before you can get to the point where teams start to self volunteer and organize. If team members leave, this process starts over again.
In these situations, the Agile retrospective becomes important to evaluate a team’s performance as well as understanding an individual team member's contribution to both the velocity and completeness of their contribution to the deliverables of each iteration. This historical data is important to have to anticipate the success of upcoming Scrum projects. A company's financial stake is on the line for the success of the delivery of Scrum projects and whether we like to acknowledge it or not, individuals in a team are paid to deliver on these projects and the only way to accurately and fairly gauge this is by analyzing in depth their performance and contribution to the project.
Individual performance appraisals are not antithetical to the Scrum process and is actually quite important to the continued success of future Scrum projects. Like any project management assessment, it needs to be done with a clear goal in mind and done up front and transparently with the teams.
Posted on: April 09, 2012 06:46 PM |
Permalink