Here is the list of most frequent questions that we receive:

Q: Capacity Tracker disappeared from by board

We have deployed a release to enable permissions on team-managed boards and hide UI elements when you don’t have the required permissions.

We have updated our documentation to guide you on how to configure them: https://inprowiser.atlassian.net/wiki/spaces/CT/pages/1729069138

Q: Log4j2 CVE-2021-44228 vulnerability

Capacity Tracker is not impacted by the log4j vulnerability. We do not use our own logging library, we use the one provided by Atlassian.

You can read Atlassian’s report on their products here: https://confluence.atlassian.com/security/multiple-products-security-advisory-log4j-vulne%5B%E2%80%A6%5D-to-remote-code-execution-cve-2021-44228-1103069934.html

Q: The Original Estimate field does not affect my data after change.

It is because we do not use the original estimate field, we only use the remaining estimate field as this is the only field that should be touched after setting the original estimate during planning.

Please only use the remaining estimate.

Q: Story points not reflected in the Capacity Tracker.

This could be possible due one of the following reasons:

1) You are using a custom field instead of Jira’s default field. We strongly recommend using default Jira fields for time tracking and estimation that includes Story Points.

2) Wrong story point field. Earlier classic projects estimation were measured on “Story Points” field in Jira. Later they introduced another default field “Story Point Estimate“ for next-gen and team managed projects that introduced a lot of confusion around Jira user community. It is a Jira constraint currently and hence a pre-requisite for tracker.

• If you are using a “Team-managed project” or “Next-gen projects”, the field should be “Story point estimate”

• If you are using a “Company-managed project” or “Classic projects”, the field should be “Story Points”

3) Duplicate story point field or incorrect use of multiple story points fields available in Jira.

• Multiple fields called “Story Points” or “Story Points Estimate”. If you are a Jira admin, you can go to https://yourinstance.atlassian.net/secure/admin/ViewCustomFields.jspa?page=1 and look for fields called “Story Points” or “Story point estimate”. If you find multiple fields, then you will have to remove the non standard one. It could be in the list of custom fields, or the Trash screen (if it is pending deletion). You can click on the “Info” icon to get some troubleshooting details, it should show you which field is currently being used by the tracker.

Indeed the multiple and wrong use of fields is confusing and the same has been recognized by Atlassian in their forums and support tickets. Atlassian might be working on a fix long term but until then please make sure you have added the correct field for your project screens, removing the other one to avoid more confusion. Your Jira administrator can help you review your current configurations and help fix as necessary.

Q: I'd like to see the capacity at the sub-task level. The Capacity metrics are only reflected at the story level.

The tracker pulls everything based on your board filter (issues, sub-tasks, bugs, etc) and process them the same way. So if your filter includes sub-tasks, they will get considered in the tracker.

Make sure to check your board's filter.

Q: Do you have an API?

We provide a REST API, you can check how to use it here.

Q: The scroll does not work, I cannot see the full page.

Make sure the version of Capacity Tracker you are running is the latest version on the marketplace.

This is most of the time related to an unsupported, older version of JIRA.

Q: Is historical data available?

Capacity Tracker is not a planner, only a tracker. It does not store historical data.

That being said we provided a CSV download ability so you could download the data at the beginning and the end of the sprint to be able to compare.

Q: I'd like to see an overview of all my sprints, all at once.

Make sure to update the capacity tracker as this has been implemented in our latest release.

You can find the consolidated view in the sprint dropdown on the top right corner of the tracker.

Q: How do I switch from Sprint Based and Version based capacity tracker?

Sprint or Version based are automatically set by the Tracker on top of each Jira board settings depending on the project board type. If the board is an Scrum board then the period for capacity tracking is a Sprint. if the project board is a Kanban board then the period for capacity tracking is a version (also, called release/fix version). So if any items within a board use a version and this board is not an Agile board then tracker consider this board a version based.

Q: How do I add/change/remove roles?

We have set some default options (Analysis, Dev, Test, UX). Because these do not fit all use cases we also have implemented a way to add your own roles. The Custom option allows you to create your own category, however as it is not stored in a database the workings will be a bit different than a usual add/change/remove process.

Indeed, we only store the role in the user configuration, meaning that we will parse the configuration each time you load the page and collect all unknown roles as Custom. After a role modification, if the “count” of a custom role (the amount of users that uses this particular role) reaches 0, the custom role will disappear from the dropdown selection after the next reload.

So if you’d like to modify a role, you will need to create a new Custom role, assign all the users in this sprint that used the former to the new role and reload. This will effectively remove the previous role from the dropdown. The same operation will work to delete a role.

Q. Why is it not possible to edit sprint start and sprint end date in Capacity Tracker after the upgrade?

In earlier versions, The Capacity Tracker used to offer a setting to configure the start and end date for future sprints. Later, Jira started to handle start and end dates on active and future sprint, and the functionality therefore became redundant and was removed from the tracker to integrate fully with Jira. Now, Capacity Tracker uses the actual start and end dates configured in Jira while working with the sprints.

Q. Why do I see discrepancies in the dates/duration between Jira sprint configuration and Capacity Tracker?

When setting your start and end date in Jira you will need to make sure to account for your timezone, as dates are stored in Jira on the UTC base. You will need to make sure the time you input reflects your timezone, else you will run into discrepancies. The tracker works in full days and not hours. This design was implemented consciously as we do not know what timeline within a day your iteration will be set in. Therefore, if you’d like your dates to be accurately reflected in the tracker you will want to pay attention to the UTC value of you start and end dates and especially the times. Jira will store the times as UTC and therefore, as we use time zones, it might set your day back or forward depending on the users timezone. You can click on the "info" button next to the Team Member section on the tracker to see how the tracker is interpreting Jira’s data so you can adjust the time accordingly.

Please refer the example below, it describes few important considerations and differences while working with the dates.

Example: Let’s say you're a user based in New York and have selected 2 weeks as duration for your sprint and the start date is set as 07/Dec/21 11:00am.

• Sprint duration difference between Jira and Tracker:

  • This will auto configure the sprint end date as 21/Dec/21 11:00am by Jira. For Jira it is 2 weeks iteration i.e. 10 working days considering the time factor of the date. And it will store the dates in UTC. Start date (UTC): 2021-12-07T16:00:00.000Z, End date (UTC): 2021-12-21T16:00:00.000Z

  • The Capacity Tracker works in full days so there are 11 working days if you count starting from 07/Dec/21 including 21/Dec/21. To fix this, we suggest you use custom duration and set end dates manually instead of using default sprint duration like 2 weeks / 3 weeks in Jira. For this example, you'll need to edit the sprint and select 20/Dec/21 11:59pm as end date and you will get an accurate 10 days of working capacity.

• Working days difference for members in different timezone:

  • For the same sprint, If you have two team members one in New York USA and other in Sydney Australia. The tracker will apply the timezone differences with base UTC time. Member 1 (NYC): Start date (local) will be 2021-12-07 and End date (local) will be 2021-12-21, Member 2 (SYD): Start date (local) will be 2021-12-08 and End date (local) will be 2021-12-22

Q: I have a licensing questions (trial extension, refund, etc.)

We unfortunately do not handle licenses, Atlassian does, we advise you to contact them directly in order to save time. You can do so by following the link to their marketplace support portal: https://support.atlassian.com/

Q: My trial expired and/or I would like an extension.

We unfortunately do not handle licenses, Atlassian does, please contact them directly in order to save time. You can do so by following the link to their marketplace support portal: https://support.atlassian.com/

Q: How do the issue type filter work?

We provide an easy way to filter the Jira issues the tracker should use when computing the capacity report. Please note that this filter is applied after your Jira board filter.

It means if your board filter does not include a specific issue type, we will not be able to use it even though you specified it in the tracker settings.

Please, do note that because of Jira’s own limitations we are not able to load the list of issue types for boards that contains more than 25 projects. This means that the feature will be disabled.

If the filter was set, the filter will remain applied and will not be changeable anymore.

Q: Do you support Jira server to cloud migration?

Yes, we do support server to cloud migration through Jira Cloud Migration Assistant. As an alternative, we provide a manual way to export/import data through the CT admin configuration page. However we highly recommend you to only migrate through JCMA and not manually. For more details, please refer App Migration documentation page.

Q: I want to contact you.

If you would like to get in contact with us, please open a support ticket and we will come back to you.