I am writing a report which requires the analysis of performance of each individual team member in my team.

This is for a software development project developed using the Unified Process (UP). I was just wondering if there are any existing group appraisal metrics used so I don't have to reinvent the wheel.

  • In regards to the bounty on this question, I'd say that an answer would need to go beyond a simple link to the Programmer Knowledge Matrix (goo.gl/Cmfx)...
    – Tiago Cardoso
    Commented Jan 23, 2012 at 12:39

6 Answers 6


Please don't measure individual performance - the team succeeds or fails as a unit. Measuring individual performance is somewhere between difficult (How do you deal with pairing? How do you measure the contribution of architects, designers or other non-coders compared to coders?) at best to divisive and counterproductive at worst, see "The Darker Side of Metrics" by Douglas Hoffman for examples of what happens when you try to measure software productivity.

Team performance is already adequately covered by existing XP or dX methodologies. If you want to do Agile with a UP foundation, as a previous RUP consultant I strongly recommend "dX, a minimal RUP process" by Grady Booch, Robert C. Martin and James Newkirk. It is no coincidence that 'dX' is 'XP' upside down! :-)

  • 5
    If you don't "measure" individual performance, how do you give raises or promotions? How do you know whether someone should become a "lead", "domain expert", or otherwise senior member? Or is this excluded by the Unified Process definition? (I don't know much about UP) - or is your dislike of "measuring" only against concrete metrics that are known to be worthless for evaluating competence, like number-of-lines-of-code, or number-of-defects? Commented Jan 9, 2012 at 10:08
  • @MerlynMorgan-Graham - Fox is right - that is the worst thing you could do. It would kill team work and effectively your projects. See my answer for details why and what you <b>should</b> measure. Commented Jan 23, 2012 at 16:32
  • @DannyVarod: FYI, I was playing devil's advocate :) Glad it spurred you to answer those questions yourself. Commented Jan 23, 2012 at 18:53

The are a few kinds of contributions e.g:

  • Analysis of problems and translation to UX, requirements
  • The production of design
  • The production of working code and unit tests
  • Creation of integration and system tests
  • Pairing up with another developer on his/her machine
  • Guiding another developer or reviewing others' products
  • Debugging bugs and fixing in any code (by any author)

Ideally, any developer should be able to get his hands dirty in any code, to get the work done - so measuring by metrics on area of code is wrong.

Measuring by lines of code is completely idiotic (sorry to have be the one to tell you this). See example here. The quality of the code matters - not the quantity. In fact shorter is often better.

Measuring by number checked-in components is wrong - doesn't account with non-coding work and pair programming (which happens all the time, even if not officially). Also this ignores quality.

The ultimate bottom line is team work, not the work of individuals.

The time spent guiding others is often more important than the time spent working alone.

If you reward individual performance you will be ruining the team work and making your projects fail in the long run. (See this link.)

What you should measure is things like (not a full list and not in any specific order):

  • Research and Innovations - self learning, solving (design or code) problems using unique thinking, introducing others to new technologies and methods
  • System vision (seeing bigger picture beyond single tasks)
  • Quality of design (maintainability)
  • Quality of code (readability, test coverage)
  • Completion of personal commitments on time
  • Responsibility - does the developer make sure outputs are usable and depended tasks aren't stuck and help others complete depended tasks when necessary
  • Guidance - does developer help others when possible if they need help or to maintain quality of teams outputs
  • Adaptability - willingness to consider changes and new ideas
  • Does developer take on tasks upon himself beyond his personal responsibilities
  • Communication - does developer communicate well with team

The above are important factors in deciding seniority, accomplishments, rewards and etc.

Team leaders should be chosen by team leading skills, not by coding skills. E.g:

  • Project management
  • Analysis
  • System vision
  • Guidance
  • People skills
  • Ability to listen to anyone
  • Ability to drive others, whether subordinates, bosses or neither
  • 1
    That's a very good and thoughtful answer, thanks Danny! Besides, I completely agree that less code means better code.
    – Tiago Cardoso
    Commented Jan 23, 2012 at 17:34
  • +1 for demonstrating what you should be on the lookout for. How do you truly measure the things you're mentioning? Is there any scoring system that can be used for each of them? Commented Jan 23, 2012 at 18:58
  • Yes, however not automatically. Many companies hold periodic performance reviews, prior to which all employees and their direct managers are required to recall (in writing - in brief) all they have done (including non-personal tasks) since the previous review and then grade themselves (using a non-numeric scale of 1...5) on the above according to what they have done. Each employee then meets 1:1 with his/her manager and the manager makes modifications as necessary (in both directions). Look up material on performance reviews for more details. Commented Jan 23, 2012 at 19:22
  • +1 for a detailed and thoughtful answer. The points of evaluation mentioned are same as I use for evaluation. Also very important is to give periodic feedback so that there is a chance of improvement and performance evaluation in the end does not come as surprise.
    – asolanki
    Commented Jan 26, 2012 at 16:59

I agree with @Fox that the individual performance evaluation might be dangerous and unfair, but if you still would like to do it - or you have to do it - then check on the 360 degree evaluation feedback (the wikipedia article). We used it with the addition that the evaluators had to put an ordered list together with the names of the team members including themselves. After merging the different lists and opinions together we had a clear view on the team members' relative (to each other) performance.

  • With all due respect, I think that "a clear view on the team members' relative performance" was exactly what your process was guaranteed NOT to provide. For relative appraisal, you need a common set of objective criteria. 360-degree is subjective. Say your star programmer stayed up late working on a tough problem only he can handle. He slept in, skipped his shower, rushed to work for a morning meeting the day folks wrote their evaluations? Would his talent, dedication and resultant slightly odd aroma not affect his relative standing on the team? We'd like to hope not, but can you be sure?
    – ghoti
    Commented Jan 20, 2012 at 18:22
  • I learnt that when we are talking about evaluation it will never be objective. Even if you have criterias, people will fill out forms based on their feelings, impressions and views. For example, your manager asks you to rate your colleague about "how hard is she working" in a scale 1..5. What is 2 or 4 in this context? I'm I a 3, then she is a 2? Maybe. If the questions sound like this "Is she working harder than you?" than the answer is a bit more easy. + in our case almost 50% more colleague gave us the ordered list than filled out the previous survey.
    – Zsolt
    Commented Jan 26, 2012 at 13:56

Measuring individual performance is critical, and part of an individuals measurement must be their own performance AND importantly how well they contribute to the team. The output and behaviour of the team is an aggregate of the output and behaviour of the individuals.

You should not blindly use metrics and I would agree with the other posters that blanket metrics use eg: lines of code per hour or number of defects per hour is a fools game. But, you need to measure their performance.

A team is a collection of individuals. If you treat your top performers the same as the bottom performers, your top performers will become disgruntled and leave while your bottom performers will get a free ride.

  • 1
    Re: @Danny Varod answer - if I could I'd +1 the answer and comment - I completely agree and would flag that while Danny states "If you reward individual performance you will be ruining the team work and making your projects fail in the long run." - he then provides a list of ways to measure individual performance (self learning, introducing others to ideas, communicating with others, code quality, helping others, timeliness). All items that an individual does on their own AND that will allow you to measure their performance directly while also measuring how they contribute to the team.
    – jasonk
    Commented Jan 25, 2012 at 5:43
  • Jasonk, I believe you have now enough rep to comment on @Danny's answer, removing this one.
    – Tiago Cardoso
    Commented May 4, 2012 at 12:23

This is how my team does it: https://pm.stackexchange.com/a/21343/26783

We broke the Scrum process a bit by keeping the titles (Senior (SR), Mid, Junior (JR)), but only for salary and compensation benchmark.

To keep it on the fair side, we have a SR in each Scrum Team (also called technical lead, but not people lead, so not manager; they are supposed to lead the technical side of the product).

Tools we use:

  • feedback 360 (in case the SR in a team is biased regarding the people in the team)
  • feedback from the SRs on their technical capacity and from Scrummaster (SM) on their process knowledge (90% of the time the feedback 360 and the SR/SM feedback as similar; when discrepancies, we ask the CTO to find the facts)
  • we also ask the entire team where they position themselves, where they want to be and what they need to get to the next level with all the information above we have a meeting (the seniors in tech), we look at where they position themselves;
  • if nobody disagrees and the feedback is on point, we position the developer on the level he chose for himself; if feedback or SRs say different we have a discussion, we motivate why we don't see the developer on that position and what they have to do to actually be there (with a timeline and a responsible mentor / guide for them).

The system is quite fair. The salary brackets for each level is open to everyone; where everyone is also public to the entire team. So they kind of know their own salaries, it's all fully transparent.

When we communicate the results to the developers, they have an occasion to contradict us (with facts). Never happened so far :)


You don't specifically mention Agile, but there are hints of it in there. Even if that is not the operational mode, the following points are still applicable.

One of the benefits of properly embracing and executing the Agile philosophy is truly collaborative teams, not a group of individuals assigned to work "together" (i.e. answer each others' questions) under a single manager. The team works toward creating quality, valuable products. Framing thins on individuals can be an impediment to team development and maturation.

The majority of the goals need to be team oriented in order to facilitate the team concept. These are generally manifested in Sprint Goals. Limit scope and time to ensure quality and reduce risk. Focus on the team's short term mission. Creating and attempting to adhere to longer range planning will lead to disappointment. (see history)

Any individual goals need to be tailored to that person and not be based in what the team accomplishes. For example, achieving X story points is bad as an individual goal; it can also be bad as a long term team goal. (It also goes against the "maintain a constant pace" principle.) Instead individual goals should focus on items such as skill or education.

Velocity is not something that needs to be continuously improved. (again see "maintain a constant pace") It is one tool option for forecasting the possible completion of future work. It is not a measure of productivity. (see "Working software is the primary measure of progress.") Is creating pressure to essentially work faster/harder beneficial for results?

tldr; Base individual goals on the individual, not on the team.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.