KPIs as a compensation-and-reward system in a Scrum environment

Sorry for the broken link. You can find the post here

In my understanding, Scrum is coherent with collectivistic principles, where the team is more important than the individual, and where individual interests should be subsumed under collective interest. Under a collectivistic mindset, KPIs about individuals mean nothing next to the success of the team.

On the other hand, if you have an individualistic mindset, which is the cultural trend in most of the Western world, then you will agree that individuals are separate from their team. You will value personal development, because individuals may one day leave to join another team. Under that mindset, individual KPIs definitely have value.



I would agree that Scrum, in principle, conflicts with personal KPIs. Does that cast a shadow over either Scrum or personal KPIs? That would depend on your values.

In Scrum, it ought to be possible for a team to describe the qualities of a good team member. Opinions on this may differ between teams, and valued qualities may change over time as the team inspects and adapts.

Here are some examples which might articulate into KPI's which are owned and assessed by a team. They aren't necessarily equally weighted.

What a good team member will do:

• Agree with other team members and the Product Owner to deliver a valuable and achievable piece of work every Sprint
• Understand the Sprint Backlog and how it correlates to the Sprint Goal
• Participate fully and actively in daily standups, planning sessions, reviews, and retrospectives
• Work with the rest of the team to meet each Sprint Goal (self-organize)
• Help other team members and the Product Owner to clarify requirements, such as by writing user stories and acceptance criteria
• Pro-actively remove skill silos, such as by pair programming or cross training, and without being told to do so
• Work with the Product Owner on an ongoing basis, so that work is understood, reviewed, and approved continually
• Make sure that the work done is transparent, such as by updating Scrum and Kanban boards
• Understand that they, and all team members, are stakeholders in the agile process
• Estimate work so that the Product Owner and other stakeholders can plan ahead (e.g. for release planning)
• Fully support and encourage the elicitation of metrics, and be able to interpret them and act on them
• Resolve outstanding or impeded work before actioning new work from the backlog
• Limit work in progress so as to maximize throughput
• Act immediately on impediments by appraising other team members and the Scrum Master of any issues, and help to resolve them
• Accept personal responsibility for the team's success
• Accept personal responsibility for their work meeting the team’s Definition of Done

What a good team member doesn’t do…

• Fail to give the best unpadded estimates that can be provided at the time. Estimates should be given and received in good faith.
• Cherry pick work from the Sprint Backlog. The backlog is owned by the team and must be actioned in accordance with the team's Sprint Plan.
• Attempt to work on more than one item at a time. A good team member will pro-actively limit work in progress.
• Expect somebody else, such as a Scrum Master, to update the Scrum board or Kanban boards. Information radiators are owned by the team.
• Work in a "skills silo". A good team member does not view their work as a speciality that only he or she is able to work on.
• Claim that work has been completed if it does not satisfy the team’s Definition of Done
• Claim that work is complete if it does not meet the specific acceptance criteria that have been agreed for it

Thanks Ian Mitchell

I'm thinking on KPI of members in scrum. Your suggestions are very valuable for me.