3 ms·

I'm facing the same problem - need to measure performance for each member of my team and indeed no easy solution here. Currently I'm measuring: - How many tic

I'm facing the same problem - need to measure performance for each member of my team and indeed no easy solution here. Currently I'm measuring: - How many tickets have been closed by each developer (we use mantis) - What is the (average, average of 5 best, average of 5 worst) time for solving tickets - For each average from above I obtain number of lines changed and also calculate average (mantis connected with git) So for given period of time I know: - how many tickets were closed by each dev - in average - best time, worst time and usual time for solving tickets - in average - amount of lines of code for worst time tickets, best time tickets and usual time tickets I then look if lines representing average score are closer to lower or upper averages. However all above is just to provide some orientation, my team is still small enough so I know each developer myself and also I'm involved in solving most issues so I base on that knowledge.

joshschreuder 11y ago
Sometimes I spend all day on one ticket to find a one line solution and sometimes I can close one in 10 minutes with a 20 line solution. I get that you want averages but even between senior and junior devs it seems like this would be massively weighted towards devs who don't pay attention or bother to look for a 'right' solution and instead go for the quickest Is tickets closed a good metric?
- ramtatatam 11y ago
  As mentioned I use this as a support indicator since I work close with my team and I know them quite well (so I'm usualy aware of such situations you highlighted). This indicator was to help me to identify potential problems rather than to make decisions about rises :-)
gus_massa 11y ago
I'm not sure about tickets, but I grade a lot of math tests. In some cases, there are a lot of easy to grade tests (almost empty, straightforward solutions, easy to read fonts, ...) and a few very difficult to understand cases. Some of the graders "specializes" in difficult to grade papers, they read very few, but the contribution is very important. Not all bugs/tickets are created equal. Just counting them would incentivize to cherrypick the easy ones.
- ramtatatam 11y ago
  That's why number of tickets is only part of the story. The time and lines of code add additional insights. Anyways this was never meant to be "precise" indicator - the goal here was to have some sort of analysis that is easy and fast to come up with.
sheepmullet 11y ago
> need to measure performance for each member of my team and indeed no easy solution here. Why do you need a hard number? If you work on a <10 person team then you should already have a good idea of how everyone is performing. I worked at one place where our bonuses were based on tickets closed and it lead to so many problems. We would get support/qa to create multiple bugs for a single issue and we then would do different fixes for each one of them even though they all really stemmed from the same core issue. A lot of bugs came in over night so a couple of us would log into the bug tracker from home and assign ourselves all the easy bugs. Devs, when they got half way through a bug and realised it was going to be more difficult than they thought would just put it back, or leave it half finished. Etc. Be very careful what you wish for :)
- ramtatatam 11y ago
  And that's precisely why number of tickets is just part of the story :-) Not sure if you have taken your time to read entire post. And indeed - I know my team and as pointed this simple indicator helps me find out if there may be problems like burnouts or if tasks rotation is right but what would you suggest to use to all those folks who are building new team? And just little comment on your first suggestion - you need to have some data supporting your story when you go to see the financial exec and negotiate rises. Your subjective opinion may mean a lot to you, but in many cases may be not enough when you want to do money talk.
  - sheepmullet 11y ago
    > And that's precisely why number of tickets is just part of the story Hopefully one you are wise enough to keep to yourself :). I've seen so many problems even with the use of relatively sane metrics. > what would you suggest to use to all those folks who are building new team? Management, not metrics. At best you can use metrics as a rule of thumb to give you early indicators of possible issues. For a new team though you need to work together with them for a while to learn about their performance and capabilities. There is no other way. Perhaps one guy in your team is thoughtful and methodical and takes a week per issue but can solve complex issues, and another girl in your team can fly through half a dozen simpler issues in a week. That's actually the kind of diversity you want to encourage and it's something you can easily destroy if you consider #tickets closed an important metric. You should never mention metrics as a measure of performance with either your subordinates or your superiors. Your subordinates will work to the metrics rather than do what needs doing. And your superiors will start relying on the metrics instead of on your judgment. For example if you collect and use the #tickets solved per month as a metric then if you need to downsize your manager will say lets get rid of the people solving less than x tickets per month. Oh wait that includes some of your best people! Now you have an uphill battle, especially if you have used the #tickets closed as a reason to promote someone in your team. Edit: Basically the potential gains are minimal and the potential issues are numerous.

joshschreuder 11y ago

Sometimes I spend all day on one ticket to find a one line solution and sometimes I can close one in 10 minutes with a 20 line solution. I get that you want averages but even between senior and junior devs it seems like this would be massively weighted towards devs who don't pay attention or bother to look for a 'right' solution and instead go for the quickest Is tickets closed a good metric?

ramtatatam 11y ago
As mentioned I use this as a support indicator since I work close with my team and I know them quite well (so I'm usualy aware of such situations you highlighted). This indicator was to help me to identify potential problems rather than to make decisions about rises :-)

gus_massa 11y ago

I'm not sure about tickets, but I grade a lot of math tests. In some cases, there are a lot of easy to grade tests (almost empty, straightforward solutions, easy to read fonts, ...) and a few very difficult to understand cases. Some of the graders "specializes" in difficult to grade papers, they read very few, but the contribution is very important. Not all bugs/tickets are created equal. Just counting them would incentivize to cherrypick the easy ones.

ramtatatam 11y ago
That's why number of tickets is only part of the story. The time and lines of code add additional insights. Anyways this was never meant to be "precise" indicator - the goal here was to have some sort of analysis that is easy and fast to come up with.

sheepmullet 11y ago

> need to measure performance for each member of my team and indeed no easy solution here. Why do you need a hard number? If you work on a <10 person team then you should already have a good idea of how everyone is performing. I worked at one place where our bonuses were based on tickets closed and it lead to so many problems. We would get support/qa to create multiple bugs for a single issue and we then would do different fixes for each one of them even though they all really stemmed from the same core issue. A lot of bugs came in over night so a couple of us would log into the bug tracker from home and assign ourselves all the easy bugs. Devs, when they got half way through a bug and realised it was going to be more difficult than they thought would just put it back, or leave it half finished. Etc. Be very careful what you wish for :)

ramtatatam 11y ago
And that's precisely why number of tickets is just part of the story :-) Not sure if you have taken your time to read entire post. And indeed - I know my team and as pointed this simple indicator helps me find out if there may be problems like burnouts or if tasks rotation is right but what would you suggest to use to all those folks who are building new team? And just little comment on your first suggestion - you need to have some data supporting your story when you go to see the financial exec and negotiate rises. Your subjective opinion may mean a lot to you, but in many cases may be not enough when you want to do money talk.
- sheepmullet 11y ago
  > And that's precisely why number of tickets is just part of the story Hopefully one you are wise enough to keep to yourself :). I've seen so many problems even with the use of relatively sane metrics. > what would you suggest to use to all those folks who are building new team? Management, not metrics. At best you can use metrics as a rule of thumb to give you early indicators of possible issues. For a new team though you need to work together with them for a while to learn about their performance and capabilities. There is no other way. Perhaps one guy in your team is thoughtful and methodical and takes a week per issue but can solve complex issues, and another girl in your team can fly through half a dozen simpler issues in a week. That's actually the kind of diversity you want to encourage and it's something you can easily destroy if you consider #tickets closed an important metric. You should never mention metrics as a measure of performance with either your subordinates or your superiors. Your subordinates will work to the metrics rather than do what needs doing. And your superiors will start relying on the metrics instead of on your judgment. For example if you collect and use the #tickets solved per month as a metric then if you need to downsize your manager will say lets get rid of the people solving less than x tickets per month. Oh wait that includes some of your best people! Now you have an uphill battle, especially if you have used the #tickets closed as a reason to promote someone in your team. Edit: Basically the potential gains are minimal and the potential issues are numerous.