I need to create a report that details number of Story Points by developer for any given closed Sprint. Right now, it's very cumbersome as I have to search the JIRA issues list using a standard query like:
project = XXXX AND status = Closed AND Sprint = 1234 ORDER BY assignee ASC
Then export the results to Excel, edit the spreadsheet heavily and then total the Story Points be developer. It would be nice to be able to create a report showing developer productivity across several sprints. While I understand that completed Story Points isn't the only metric to "grade" a developer, I feel it's as good a tool as any.
If you're up for a commercial solution, we provide an app called Dashboard Hub for Jira that allows you to create reports and dashboards of different types for different teams. It includes more than 60 metrics out of the box, dashboard templates, integration with 10 products, ability to securely share externally the reports...
One of the provided gadgets, the JQL Custom Charts, lets you easily create charts to, for example, display the sum of story points per developer per sprint:
Hope this helps!
Dear @Ed Salgado,
story points are relatively and absolutely say nothing about the productivity of one team member. Taken all story points together, done by one team, will show its velocity. The longer one team is working together, the better the velocity will develop.
The result when you publish such a ranking is, that each team member will start working on the high estimated stories, first - because there they can score best. By this, the priority, a Product Owner has given to all the stories, is sooner or later ignored.
I recommend never to measure team members individual, this will start a competition which is the killer of team interaction and the death of agility.
Measure them as a team. If there are low performers within, sooner or later this will regulate itself. Experienced teams can do this on their own - if you let them.
Thanks for your response @Thomas Deiler.
I would never publish the results of such a report. This would be for my eyes only.
With that said, I completely disagree that you should not measure developer's productivity. I would also say you need to measure them on ability to work well with others, leadership skills, etc. You should create a complete profile of each developer and understand their strengths and weaknesses. This isn't to weed out the lesser developers, but instead to figure out how/when to help them in getting better at whatever it is that they are weak in. In addition, you need these metrics in determining raises and bonuses. More data = more knowledge.
Dear @Ed Salgado,
this is probably hard to believe - but real agile teams don't need any mangers that helps them to improve. And why give them individually bonuses? When they talk together they will share this information - then the low performers are disappointed and the high performers think they are something better.
This will not lead to top teams. What you need to do is give all the team members the same bonus depending on team goals. All will fail or all will win. This makes real teams.
The mangers job is very easy. Protect your team and remove any impediment the team raises (this can also be an issue with a colleague). Shield them from destructive external interrupts. They will soon realize, how amazing it is to work for this company and perform better than before. If they need help, they will tell you. The less control the better.
Dear @Thomas Deiler,
I agree with @Ed Salgado. While I recognise the ideal you are striving for, the reality on the ground is that there are unfortunately sometimes team members who don't share the same work ethic as others or perhaps have skill gaps that they are unwilling to disclose, leaving the others to shoulder the burden of the work. Sure there are plenty of techniques to minimise this, but ultimately performance needs to be measured individually as the responsibility remains with the individual.
The argument that "education" and "team collaboration" can mitigate *all* poor performance choices at the individual level is IMHO naïve. Individuals all have choices and sometimes they don't choose to engage as we would like regardless of the team environment. Agile is not the magic bullet that solves this human dynamic.
In saying all this, I think the performance measurement of individuals needs to be carefully conducted and communicated to minimise risk of team division.
The ironic thing if individual performance is not measured - is that team division and resentment will build anyway. Members of the team will always know who the top performers are and who the poor performers are. If nothing is done at an individual level, the top performers who are always carrying the freeloaders will leave and the company will be left with a team of poor performers.
@Ed Salgado - to your original question - unfortunately I don't have an answer for you other than what you're doing. I suspect there may be a fancy query that would get the information out though.
Dear @Paul Phillips,
thanks for the reply and be that critical. I would really love more would do this!
I try to refine what I have written in January: The concequency to avoid measurement is to fully empower a team. Means they are allowed to "fire" team mates - of cause not that easy (there should be a simple process). And even if they will ged rid of the top performer - it could be the best decision to advance the team.
In the end you will need a team where all individuals somehow fit together - I don't mean harmony. Then they will perform.
The measuring manager should insted measue the team and raise some team goals (not subject related) that will push the team into the direction the most useful for the company. And this job is not easy - but affordable for those well paid managers.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event