Jira (velocity and capacity) reports.

[kafka max]

Is it possible to configure velocity and capacity in Jira if there are 4 permanent team members and 3 occasional contributors? It's unclear when and for how long those 3 contributors will be added. The employer wants to include these parameters in the workflow, but I'm trying to explain that with an unstable team, these metrics become very inaccurate.

Could you please share how this works in your experience?

[Walter Buggenhout]

Hi @kafka max,

Since you're tagging your question as related to the free plan of Jira, velocity and capacity are planned at sprint level - that means for each iteration of (typically) 2 weeks.

If your team is volatile by design, the tool is not going to fix that for you. You can, during sprint planning, of course balance the commitment of your team to the capacity you will have available for each sprint. velocity reports will simply reflect what your team delivers and give you insights on average performance over time. You can - to some extent - then use that information for longer term forecasts.

Hope this helps! 

[Mary from Planyway]

@kafka max 

In my experience, velocity and capacity can be configured in Jira, but they rely heavily on the consistency of the team. For stable teams, it's relatively easy to track and adjust these metrics based on the work completed over time. However, with an unstable team that includes both permanent members and occasional contributors, these metrics can become skewed, less reliable, and lead to fluctuations that don’t truly reflect the team's capacity to complete work.

One solution to manage capacity in such situations is Planyway. Planyway allows you to visualize team capacity in a more flexible way, accommodating changes in team composition. You can set up the resource management features to allocate different amounts of work to your permanent and occasional team members, even if the latter are not consistently available. This way, you can better manage the work distribution without relying on the often inaccurate velocity and capacity metrics in Jira.