Tracking Individual Performances in Scrum

23 January 2012

A question I've heard often is: Is it correct, in Scrum methodology, to track an individual's performance? This question has only one answer: No. Tracking and measuring the productivity of a single member of an Agile team is against the spirit of Scrum. The real question should be: If you were able to calculate such a metric, what would you do with the data? I suspect the answer is that you would use it to reward or punish on the basis of productivity, and this is something you don't want happening within a Scrum environment.

The Scrum framework doesn't prevent you from measuring whatever you want to measure. However, you'd be missing the spirit of Scrum if you measured the work of a single team member. Productivity metrics for knowledge workers are generally flawed, studies show, so you'd likely end up playing with incorrect data. 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.

It's unfortunate that Scrum tools have an "assigned to" field. Members should volunteer for stories and tasks; they should not be assigned work. It's better to think of this field as merely naming the primary person working on a task or story. I strongly feel that any team member who only does his own stories or tasks and doesn't help others in the team is a poor Scrum team member. Such behavior should not be rewarded, especially not in some kind of performance review. The best teammates are helpful and collaborative, and you can't measure their personal contribution to the team's velocity. You can only measure the entire team's velocity.

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.

The keys, then, are accurate sprint planning and a "must-do" sprint retrospective. Most important, don't wreck the Scrum by measuring an individual's work items.

Article Rating

Current rating: 5 (1 ratings)

Comments

Kalpesh Shah, CSM, 1/23/2012 11:35:16 AM
I guess a distinction needs to be called out between "individual's performance" and "personal velocity". I personally believe that personal velocity is a good metrics to maintain (not required but good to have) and should be used purely for sprint planning purposes as it can assist in planning the next sprint better and help make adjustments if that team ever will be out of office. However I completely agree that personal velocity should not be used for reward or punish for productivity. It needs to be just treated as a planning tool, no more and no less.
Manish Gupta, CSM, 3/23/2012 12:55:07 AM
I agree with your point that do not have any metric to track individual performance, however, if we do not measure individual performance, then it may work negatively for a person who is high performer. You have to pay for one's contribution in the team, otherwise, people will stop working more than what is expected from them.
MADHAVAN ELANGO, CSM, 4/3/2012 8:27:47 AM
This article reminds me of a scrum training session.

Last month, I was coaching one of the teams in my organization on ΓÇÿScrum BasicsΓÇÖ. There was an interesting question from one of the participants - "Can we introduce individual burndown charts to measure the performance of the team members?"

Like Nanda, My answer was also 'an emphatic NO'!

As mentioned in this article, Scrum does not prevent you from measuring any aspect of the software development. However, you must be mindful of the consequences of measurements such as "Individual Burndown Charts".

What would you do with the Individual burndown charts over the Sprint burndown charts?

During the Sprint planning meeting, the entire development team
- decides how much they will complete by the end of the sprint,
- lists the tasks and
- finally team members volunteer themselves for tasks

ItΓÇÖs the team that makes the commitment ΓÇô not the individuals! Hence the question of measuring individual performance does not arise at all.

Team members should help each other towards achieving the sprint goal rather than focusing just on their own tasks. Introducing individual burndown charts for the sake measuring or appraising performance of the team members would destroy the camaraderie, create competitions within the team and eventually result in spoiling the spirit of Scrum.

I second all that Nanda has mentioned in this article. It would be considered as a 'highly unethical' practice in Scrum, if you are trying to use the same to track the performance of the team members.

So, Individual burndown charts, Individual Performance Tracking ΓÇô an emphatic NO!
Rafael Leandro Junior, CSM,CSPO, 11/6/2012 5:45:08 AM
I completely agree with the article and it is certainly what we expect in Scrum, but in my view there is a gap, whenever I read something like that related to Scrum the question arises: How can the agile company promote employees? There will be no promotion and career development if nobody pay attention individually for each team member. To promote employees we must use any metric or technique that is not only "working time at the company." We need to know the employee A has evolved (even in a short time) and deserves to be promoted or reclassified. How can we give attention to this specific point with Scrum? I fully agree, we won't use burndown charts or any other sprint metrics to measure individual performance, but I think we need somehow to keep an eye on it, how? How to promote individually members of agile teams? Any suggestions?
Christopher Wood, CSM, 7/6/2013 6:28:46 AM
I can't agree with this article, I must first confess that I practice at best a modified version of Agile...not pure Agile.

We utilize Jira to track out time against tasks to help us determine two things:
1. How well our Scrum poker estimates are holding up to reality
2. How much time we're spending on task

Note that my shop has/had a very strong TSP influence that simply was not working. I introduced Agile and have been making headway, however I found value in the concept of "Time on Task" from TSP (Team Software Process).

Time on task is viewed as the actual time spent doing the actual work, not email management or phone calls. We've found value in tracking our time on task as a means of identifying intrusions. We also make time on task a goal/competition between the developers.
Checking on someone's time, especially during the Sprint, is not a good idea and I would say counter-productive. We check time on task after the end of the Sprint and use it as a guide, NEVER as a measurement for performance/awards, etc...

To finalize, tracking time with goal/competition in mind is key and should not be used to measure performance for any other reason. A scrum master and/or team leader should have valuable insight into the team members growth/skills which should be provided as input to those performing performance evaluations.
Craig Gresbrink, CSM, 4/9/2014 2:48:37 AM
It would make sense to me to rank individuals on their growth in terms of ability to follow the scrum principles as well as their ability to perform any/all the possible cross functional tasks that may be present themselves in a scrum team to complete a user story. It is doubtful that any 1 team member has no room for improvement in all 28 of these abilities. If one development team member only has 8, I'd want them to get to 12 and reward them for doing so. If one has 22, then let's get that person to 24 for example. Here are a list of ideas I had of useful cross functional skills that I feel we should use to create goals for our team members at my company and I would propose rewarding them for increasing their skills:

1. collaboration and helping other team members
2. Java development
3. Unit tests
4. Esb/Camel
5. UI development
6. Soap UI
7. Sillenium Automated UI Testing
8. Soap Web Service development
9. Rest Web Service development
10. Design and Architecture
11. Contributions to new designs/architectures/standards etc..
12. Scrum Master Certification
13. Other Scrum certifications
14. Able to be a backup Scrum Master
15. Collaboration outside the scrum team (other IT groups)
16. Collaboration with Stakeholders (within IT)
17. Collaboration with the Business Stakeholders
18. Following Scrum/Agile principles: Respect, etc..
19. Interviewing other new hire candidates
20. Assisting in Production issues and defect troubleshooting
21. Database development - new columns/views/tables/indexes/performance tuning
22. Load Testing
23. OOAD and OOP
24. Design Patterns
25. Domain Driven Design
26. UI Usability and Testing
27. Rules engines
28. Caching techniques

You must Login or Signup to comment.