Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Table of Contents

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: Team-managed Projects

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.

...

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.

...

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.)

...