Velocity by role

[Ernesto Rodriguez]

Hi Jira Community,

I have been using Jira for years but I am now in the game development space and there is a strong need for me (as a PM) to help the production team by identifying velocity by role to help them identify which roles are most understaffed based on historical velocity on a per role basis.

I'd like to say up front, I'm scrum master certified and fully aware of agile best practices and managing a backlog for deliverables is working great as-is.

My objective here is slightly different and an attempt to leverage Jira to help with resource planning, and identifying which roles are actively at capacity.

Here's what I'd like to do within Jira:

1. Segment team members across multiple projects by roles

   • 2d Art
   • 3d Art
   • UI
   • Design
   • Engineering
   • Production
   • Product

2. Once segmented, identify the historical velocity for each role

   • Over the last sprint(s)
   • Over the last quarter

Is this possible via a custom query of some sort, or a plugin available somewhere?

This sounds do-able and I'd hate to use a separate tool for this since I want all the work to be tracked within Jira.

Help on this topic would be GREATLY appreciated.

Virtual beer on me!  :)

[Bill Sheboy]

Hi @Ernesto Rodriguez 

I expect you may see some responses about "best practices".  Instead, l have some practical delivery-based thoughts I hope can help.  (And, I don't believe in best practices; only better ones.  :^)

Short answer is you may be able to do this, and it may not help with the problem you describe wanting to solve.

Your success using existing sizing history and role-based measures may not work unless the team was already using role/skill-set -based sizing or something like "things that matter" sizing, and working single-threaded on one project/feature.

For example, a cross-functional team typically gathers to size work together.  If the team is sizing by role/skill and then adding up the results, and saving the component sizing, you just need to figure out how they added and then split them back up.  If they used "things that matter" sizing, find their "things" categories and split things up. This gets more complicated with multiple teams using different "sizing rulers" (units of measure) to forecast and plan.

Without that information, I am unclear how you can use any history data to do this without making assumptions, such as:

• Everybody helped with all delivery
• We had X front-end devs, Y back-end devs, Z SDETS, etc.
• Assume a balanced workload
• We rarely task-switched between feature sets
• We rarely had abandoned work items...
• And just compute the fractions

Be that as is, you may instead consider if you have information about workflow and cycle times.  It may be more helpful to see how many things (and cycle time) flow through the value stream: product development, built assets with creative, implemented features, released, supported, etc.  There is working and wait time in there, sometimes based on capacity and more often based on other issues: WIP, defects, capacity, task-switching, etc.  At least those measures would be based upon actual counts and time, not on the relative sizing that usually drives velocity approximations.

Best regards,

Bill