Aggregating them for an individual developer over a long enough period of time might work, but I wouldn't trust it without some statistical hypothesis testing backing the idea up.
But using them to evaluate productivity on a small scale violates the collaborative culture (people over processes) that agile is supposed to foster. I've also seen them misused by:
* mapping them explicitly to hours or days
* thinking they are estimates of value produced instead of work required
* having project managers point and pull in things for developers
But, no, I've never heard of agile mistakes coming up in a performance evaluation or a 180 review for a manager.
This sounds totally insane. I Cannot believe this happens in real world.
This happens depressingly often.
"6 monts working on the equivalent of 2 weeks of estimation points"
It's really the fault of the manager for not changing something after the first 3 weeks of this.
Sometimes it's tough to be that ass and say "hey, these weren't estimated properly PM!"...but if it's your job or theirs...
Managers don't say, "So let's see who's the worst performer... it's Tom! Weird, he seems to be one of my best developers. Oh, well! The metrics say he's the worst. Off to fire Tom!"
"Best to Worst Ranking" is the most toxic and destructive environments.
Manu Cornet famous organization chart is the best example of this. https://upload.wikimedia.org/wikipedia/commons/e/e1/%22Org_c...
If you have to let go 20% of your staff, how do you do it? You have to rank people...
It sounds like justification for a decision made for less quantitative reasons.
Software development in the Bay Area and other tech hubs with similar (or aspiring to be similar) company profiles can be depressing.
Not assuming any blame is a trait neither of a great leader or an awesome person. But given the hell hole of a review process, I am not surprised the company has most likely imposter great leaders!
This is why the person doing the work must be involved in the estimation process, that way they have ownership of the estimate and are personally accountable for it.
The Gitlab performance review process is described on https://about.gitlab.com/handbook/people-operations/performa... (it is over 100 lines so I won't paste it here).
1. We have an in-house developed tool that tracks git and mercurial commits and calculates the test coverage and code quality for each individual developer.
2. We use jira to track the number of points each developer burns (points are shared between developer, reviewer and QA). We also track the number of bugs each developer introduces because closing a bugfix is not possible without first assigning the developer who introduced the bug to the jira task.
3. We use peer reviews where each team member rates each other team member on a scale from 1 to 5 (3 being considered sufficient) on aspects like availability, communication, reliability and result orientation.
4. Team leaders offer subjective input on each team member.
Of course, many of the metrics will be skewed or won't reflect the reality, which is why the team lead has the right to make adjustments to the final mark.
This being said, one of my colleagues and friend was "forced" to quit the company because he scored really low on the jira burn rate metric. He was given a tremendously huge task which nobody cared to properly estimate and break into smaller tasks. As a result he spent 6 monts working on the equivalent of 2 weeks of estimation points. The management (including the team lead which is otherwise a great leader and an awesome person) didn't want to assume any blame for this.