Please be careful when using these kind of measurements as KPIs.
If you do this, I predict the following:
arguments about whether bugs are caused by development or by poor quality analysis
arguments about which developers caused which bugs
defensive programming, which will increase the maintenance costs
developers slowing down (no code means no bugs!)
I think you're also missing a few KPIs...
Negative points every time a Product Owner changes a requirement. They should have know what they wanted before development started.
Negative points every time a tester puts in duplicate points. Perhaps they get positive points ever time they find a bug?
Negative points to HR every time a "good" developer leaves ...
This is a bad idea on so many levels.
Lets list the ways:
Builds blame culture: everyone will be trying to blame everyone else for bugs that are found because it will affect their review
Encourages people not to take responsibility. If you do accept responsibility (it's my bug) then you get penalised
Hurts inter-team relations. Developers and testers ...
Performance reviews based on bugs is a pretty bad idea imho.
Even in best case scenarios where testers are assumed to be doing perfect work, it's very hard to implement some sort of bug tracker that doesn't produce side effects.
What you might consider is using some sort of metric for re-work hours. That tends to work better because:
You aren't telling ...
Deconstruction of the Project Manager Goal
As a project manager, I could say something like "I will lead and execute X projects on time and in full with 95% satisfaction."
Setting aside whether this sort of goal really fits the SMART criteria even for a traditional project manager role, it is not appropriate for a Scrum Master role. Here are some reasons ...
I work in a team where our main goal is to maintain large projects. I pay attention to numerous things connected with technical skills in my team:
Tests - Is this person writing tests? How do they look? Does he tests before, or after? Does he write tests for bugs reported by client? We've decided that automated tests are crucial to sleep well and not to ...
I am planning to give 40 points (my scoring system) to a developer, if he creates bug free code.
How about asking the programmers how much (money) they will fork out if somebody could show them how to create bug free code? Professional coding is no easy task and there are much better ways of judging good programmers.
Here is some reasons one ends up with ...
checking SVN in a daily basis to review codes and to assess how much codes have been committed by each developer is a good way. is it fair and used in industry?
The proposed metric is utterly unfair, regrettably is used in some organisations and is in my personal opinion a recipe for disaster.
HasaniK and Jakub have already identified some very valid ...
When anyone asks this question in this way, it implies the desire to measure for the sake of measuring, an end versus a means to an end.
You metrics pop out as a result of decomposing your project goals. Any other measurement that has no parent goal will be looked at by bored stakeholders, who will eventually learn to ignore that report. Goals are ...
I have seen almost any day but Monday and Friday, because people want to leave early on Friday (assuming you have flex time) and might come in unpredictably late on Monday if they are contractors that went home over the weekend and only arrive in your city on Monday morning. Those days are also prime targets for single days off to have a long weekend and in ...
Setting a target like number of bugs is something easy to trick, and it is easy to find somebody who the others can blame. This will kill your team cohesion. Please don't measure people by the bugs they introduced. If you do so, they won't commit anything until they are 100% that it is bug free, and you'll never have a release. While I wrote this answer I ...
checking SVN in a daily basis to review codes and to asses how much codes have been committed by each developer is a good way. is it fair and used in industry ?
This is definitely not a correct measurement for a PAR for Software Engineers. As Jakub has also mentioned, design takes time,sometimes there are blockers which prevent dev team from finishing a ...
You already know you shouldn't do this. However, if you must do it, focus on team integration and support of team values, rather than trying to perpetuate the 100% utilization fallacy or applying irrelevant metrics like lines of code written or bugs stomped per iteration.
If the person makes the team better or the process more effective, then they ...
Velocity is based on guessed values, and a median over the last few sprints/iterations.
Therefore, the value is not exact as such, but it is "exact enough" for looking into the future of the next few iterations.
If you have a team of 8 people working in two week iterations, you would accumulate 80 man-days of "working power". If you want to recalculate the ...
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 (...
The objections all of the contributors are on target and these are true with all KPIs. You establish a metric to increased desired behavior, that desired behavior is "paid for" by the removal of other behaviors, some of which are also desired. This is why establishing your KPIs is very challenging and you need to do so with care.
A balanced approach is ...
Evaluating Scrum Masters is one of the toughest challenges in my opinion, because if she does the job well nobody will really realize it, but when things go wrong, she will be first one held responsible.
What criteria should the Team Members, the Product Owner and, other stakeholders take into account in order to assess the performance of the ScrumMaster?
Quality is a process and not a simple measure of "defect" rates. You improve quality by creating a better process, from start to finish, stretching across all levels of the organizations. Penalizing one role in the value chain will not help you accomplish your goal.
I once worked in that kind of environment and guess what? I left this place with rage and in very bad terms. And that is what you're going to suffer from if you indeed try to measure your developer's proficiency based on their bugs.
You're doing it all wrong. Here's how we fixed it back in the days:
Make a complex yet short printed list of the most ...
To be honest, I believe you shouldn't. In my opinion there is no fair way to measure this. No programmer, no matter how experienced he is, will create bug free code. Sometimes bugs are obscured by other bugs. Sometimes bugs evolve from interaction of two separate pieces of code that on their own are free of bugs. Maybe really severe bugs will stay ...
So here's the ultimate question: what does an accurate estimate mean?
For me, accurate estimation is like the unicorn: people are looking for it, love to have one at home, but actually it doesn't exist. :-)
Instead of accuracy I tend to use likeliness and focus on certainty. Calculating the likeliness, I'm using the distribution of lead time idea from ...
Acronyms and initalisms are useful shorthand when discussing a problem domain with others who share the same lexicon. However, such shorthand is highly contextual. For example, an "R.A." might mean Risk Analysis in an information security context, but a Residential Assistant in a college dormitory.
Inspect-and-Adapt Your Communications Plan
I can definitely feel your pain on this one. Unfortunately, it seems like the organization hasn't grasped the team concept of Agile. If your role is the SM, I would encourage you to educate the managers and directors on working differently. Agile/Scrum changes everything about the way we work, even the way we manage and review individuals.
An example you ...
Read this answer with enthusiasm and an open heart :)
I'll answer the question “how to ensure that developers voice slow developers -or. In general any issue-“ instead of “how to detect slow developers” as I think that's not the underlying issue.
The way to accomplish this in a nutshell is:
Create a safe environment. Everyone should feel safe about ...
The good news is that money has been shown to be a very weak motivator in many studies. The increase one may exhibit by money is short lived.
A guy named Daniel Pink argued that motivation is intrinsic and can be divide into three factors:
Start your research here.
This doesn't mean you can ignore the money. You need to meet ...
This is a prime example of "measurement disfunction".
Any attempt to reward or penalise an employee based on a hard metric will fail. The employee will be smart enough to game the metric, and usually to the opposite effect that was intended.
It's been covered very well by Joel Spolsky in these blog posts:
The Econ101 Management Method.
Sorry for the late answer but I just discovered this forum and joined it.
There are many ways to look at documentation so I have to make some question (and assumption) to limit the field of this discussion.
The first question is: are we talking of end-user's documentation (HTML files, printed manuals, etc.) or developer's documentation (JavaDoc and the ...
A previous answer that I wrote here on Project Management Stack Exchange provides high/low/nominal values for source lines of code written based on project type per staff-month. More specific data is always better - using historical data from your past experiences or past projects at your company of similar size and scope - would be more relevant. As you can ...
I agree with other answers here about the slower person. But why is other person person faster?
I once had someone on my Scrum Team who was so much faster than anyone else:
They wasted no time validating their ideas with colleagues (e.g. testers).
They were unemcumbered by team agreements e.g. test-driven development (TDD) approach is much to be slower ...
You are entering dangerous territory here. Why?
Because programming is an art.
If you start measuring things like lines of code written then instead of writing clever code, they will write verbose code.
If you start measuring things like tasks finished then they will finish lots of tasks, but ignore quality, like implementing corner cases.
If you start ...