Jira data on Colfluence page (cloud)

Question

Hello Everyone,

I'm sorry for multiplying old questions but I haven't seen solution for my scenario so far.

I've been asked for presenting (in Confluence cloud) data from Jira (cloud). Data would concern team members development/progress.

That means I would have to get number of solved issues and story points for each developer for each sprint. Idea behind is to see how our new colleagues make progress from sprint to sprint and decide if we should implement some more training for some of them.

There is some feature in Jira "workload by Assignee" that partially does the job but the problem is I don't know how to pull those data to Confluence page.

I asked this question to Atlassian but they redirected me to the 3rd party companies :( .

Thank you in advance for any help

Piotr

Piotr Butynski · Answer

Abel,

Thank you, of course you are right.

What we are trying to achieve however is not some tool to control and punish anyone :) . It's about showing some trend (from let's say 10 last sprints).

It might be that tasks within the sprint should be managed in different way. Maybe that can be some lessons learned for management because I think that everyone should learn and adjust.

Anyway thank you once again for your answer,

Piotr Butynski · Answer

Brant,

Unfortunately none of these tools/features let us calculate story points :(

Most likely we'll have to buy some third party solution.

Thank you for your answer.

Abel Lineberger · Answer

OK - so I am going to try to take this out of a "tools" discussion and into a "culture" discussion.  In most agile methodologies, Velocity (story points per sprint) is a team aggregate.  Moreover it is only measured as an average over multiple sprints (minimum 3).  There are very solid reasons for this.

* The TEAM commits to the total sprint plan not the individuals, and the stories within the sprint plan really shouldn't be assigned to specific members (no specialists / silos).
* An individual's velocity within a sprint can differ based on multiple factors:* They pair programmed ("slower" but higher quality code)
* They spent more time in code review for other team members
* They spent time mentoring or helping another team member
* etc - IE "unlogged" activity

* The TEAM's velocity by each sprint may vary based on undiscovered issues, spike variations, and "failing fast".

I would suggest that need for training, new member integration, etc would and should come out in the Sprint Retrospective.  I would highly encourage that your dev team have an individual retro (with or without the SM but certainly without any product management) in addition to the Sprint Retro.  They should feel free to discuss and plan how the team itself could code better in future sprints during that retro.  If they decide members need more training the team should raise the issue with the Scrum Master as an artifact coming out of the Retro.

What I am trying to say is that one of the key goals of agile development is to value individuals and interactions over processes and tools.  Confluence is a tool, not an interaction.