Tracking progress of a team working on small tasks

Question

Our software team works on small tasks. Each task takes about 2 weeks. There are developers whose performance is twice bigger than the other's (the level is the same).

Everybody just writes how much time he has spent on a task Jira at the end of the week (in Jira). It is difficult to find out whether someone's task is easier or somebody just works slower.

I'm thinking of the way to introduce kind of a metric to measure their performance, so that we can determine which developer needs help and which developer can instead provide help to the others.

I also want to track the team's performance over time - is it increasing or not.

The problem is that the tasks are not standard, they differ, so each task can really take different time. The problem is also that it is very difficult to know whether the time is spent effectively or not. And what the time is spent on.

Answer 1

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 tracking how long they spend at their desk as opposed to the water cooler you are shooting yourself in the foot; the best art (and programing puzzles) are solved when relaxing, talking or working out.

The one thing possibly worth measuring is how many bugs are created by whom. But that doesn't help you measure performance, only who needs help.

Bottom line:

• Trust your team to behave like adults, and they probably will.
  • Treat your team like naughty kids and they will start behaving that way
• Work on team building - a real team will create its own hierarchy and the stronger (and faster) members will help the weaker ones.
  • And the weaker ones will turn to the stronger ones for help.
  • Unless you start measuring individual output/performance, and then they start competing against each other.

So instead of introducing some kind of a metric to measure the performance of individuals, introduce team-building exercises - and treat the team as a whole.

Answer 2

I feel that this approach, trying to determine team performance from above, might not be perceived well by the team and may backfire.

As another answer noted, this may well turn your team's focus into looking productive rather than being productive.

Some people may do it just to protect their jobs. But I also know from experience that people love to game the system.

My department had the same kind of questionings going on. We had an opportunity to bring on timesheets, but we refused. Instead, we began rolling out some self-assessment metrics for the teams - while this may not be a big-bang approach that people expect, we felt this would benefit all teams in the long run.

By getting the teams involved in the process, rather than just bringing something from the top to "evaluate" their performance, they feel more secure and can be more open about the kinds of changes they need. Remember they're professionals - and if you treat them as such, they might surprise you with how much they care about what they do, and how to improve it.

Answer 3

I'm assuming your dev methodology is Agile (or SCRUM?) and if so, then these are pretty big "Tasks".

In JIRA I'd call the size of work you're describing, a Feature. Features should be broken down into User Stories. User Stories broken down into Tasks.

But the answer to your question is Story Points & Velocity.

Here's a great post by Atlassian describing and explaining how to use Story Points and Velocity in JIRA.