Skip to content

Releases: bitovi/jira-timeline-report

Status Reports for Jira

31 Dec 16:06
Compare
Choose a tag to compare

Overview

We made the following changes:

  • We renamed the app Status Reports for Jira. This reflects Jira's trademark requirements and focuses more on what the app attempts to do - automate statue reporting for Jira.
  • The plugin layout now removes the header, making the UI look much more seamless when the app is used as a Jira plugin

image

What's Changed

Full Changelog: v0.8.2...v0.9.0

Saving Reports MVP

18 Dec 03:41
Compare
Choose a tag to compare

Saving Reports MVP

The saving reports MVP UI is now released. Users have the ability to create / update / copy / delete and rename reports.

Jira_Timeline_Report

What's Changed

Full Changelog: v0.6.0...v0.8.2

v0.8.1

11 Dec 17:12
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.6.0...v0.8.1

Team-Issue Configuration and Saving Reports MVP

09 Dec 15:23
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.6.0...v0.8.0

Team Configuration and Spreading Estimates

24 Oct 02:48
Compare
Choose a tag to compare

This release brings:

  • Teams Configuration - Configuration settings specific each team
  • Spreading Estimates - Instead of using primarily dates to determine how much work is complete, use the estimate spread across the dates to determine how much work is complete

Teams Configuration

Different teams might use different settings for dates, estimates, etc. You can now configure these in the Teams global settings sidebar menu:

image

Clicking the Teams button will show a list of teams that can be configured individually:

image

NOTE: A team is either the team field value or the project key (if there is no team)

Clicking a Team lets you configure that team's settings. The following shows the BUY team's configuration:

Jira_Timeline_Report

Notice that the team is inheriting all it's values from the Default Settings. To change this, click CUSTOMIZE and then change the value. For example, the following sets the BUY team's velocity to 25:

image

Spreading Estimates

The percent complete rollup would use the timing of issues to determine how much work has been completed. For example, an issue that had a start and due date 20 business days apart would always be considered as 20 days of work.

This doesn't make sense for work that is spread out over time. For example, lets say some work is 5 days of work, but is going to be done over 20 days. You'd want to spread that 5 days of work over 20 days. This is exactly what the new Spread effort toggle does ... turning it on:

  • spreads your estimate across the dates to determine how much work has been done, and
  • uses the estimate as the total amount of work

Let's see an example!

The following 3 epics use a Days Estimate field to track the amount of work they have to do. However, they all share the same start and due dates:

Timeline_-Baseline_Report_Testing-Plans-_Jira

Each epic's start and due dates are 20 days apart. If we look at the base behavior of the Baseline Report, it will show each of these epics as needing 20 days of work:

Jira_Timeline_Report

However, if we configure to spread the estimate across time:

image

Now you can see the total work is calculated from the estimate. The percentage of work complete is still using the dates. But the percentage uses the estimated work for calculating completed and remaining work totals.

Jira_Timeline_Report

What's Changed

Full Changelog: v0.6.0...v0.7.0

Estimation Table

16 Oct 19:46
Compare
Choose a tag to compare

Estimation Table

image

This adds the start of an Estimation Table report to help understand your project's estimates and how percent complete is calculated. It's very rough right now, but look for enhancements shortly.

For each issue type it will show:

  • Estimated Days - The provided estimate converted to days. If no estimate was provided, the cell will be blank. If the estimate has changed, it will show Previous => Next values. You can also click the Estimated Days value and see a breakdown of how the value was calculated (more on this below).

  • Timed Days - How many business days are between the start and end of the issue. If the estimate doesn't have dates, the cell will be blank. If the timing has changed, it will show Previous => Next values.

  • Rolled Up Days - How many days of work are used to represent the issue, comparing children estimates, and the issue's estimates and the issues timing. More below on this calculation.

Estimated Days Tooltip

When you click an Estimated Days value a tooltip will appear with the following information:

image

This breaks down how the current and last (previous) Estimated Days values are calculated.

There are 3 equations:

Estimated Days = Adjusted Estimate / Points per day per work track

The estimate is the "Adjusted Estimate" divided by the amount of Points of each parallel work track the team can do.

Adjusted Estimate = Median Estimate * LOGNORMINV( Confidence )

The adjusted estimate is the "Median Estimate" inflated with a log-normal distribution using the Confidence.

Points per day per work track = Estimate Point Per Sprint (Velocity) / Parallel Work Tracks / Days Per Sprint

Points per day per work track is how many points of work the team can do on one "parallel work track".

This is the number of points a team gets done per sprint divided by the number of tracks they typically run in parallel divided by the number of days in a sprint.

Rolled Up Days

Rolled Up Days is calculated as follows:

  1. Set the issue's self timing data to Timed Days if it exists, then Estimated Days if it exists, then the average time for the issue type.
  2. Sum all the issue's children's roll up values as children's sum
  3. Use whichever is bigger issue's self timing or children's sum

The psuedo code might look like:

Rolled Up Days = MAX( CHILDRENS_SUM, TIMED_DAYS | ESTIMATED_DAYS | AVERAGE_FOR_TYPE )

What's Changed

Full Changelog: v0.5.0...v0.6.0

v0.5.1 - First step towards the new design

10 Oct 03:24
Compare
Choose a tag to compare

This is the first step in a series of steps to move the app to a new technology stack and user interface. We are migrating to Atlassian's design system to make the timeline report feel at home as an Atlassian plugin.

Functionality is mostly the same. It's just spread across new controls. The following goes through what's in each of the controls.

Jira_Timeline_Report

Top Panel

image
  • Configuration Issue - This is how you previously (and currently) can specify your teams' velocities and sprint lengths. This is eventually going to be replaced by the Teams global configuration.

  • Instance Selector - If you have multiple Jira instances, this is where you select which Jira instance you want to load data from.

  • Saved Reports - This lists your saved reports. There's a new interface coming soon for this.

Side Panel

image

Sources

image

Specify the JQL you want to load. You can optionally load all the children of your primary JQL. You can also specify filters on the children. For example, you might want to add a status != Canceled if you don't want to load canceled children.

Finally, you can also exclude certain statuses too with the Statuses to exclude from all issue types control.

Timing

image

The timing panel controls how data "rolls up" in your report. For example, how dates are determined between parent and child issue types.

⚠️BREAKING CHANGE⚠️ Previously, the default was use the parent's values and only if the parent doesn't have values look at the childrens' values. The new behavior is to take what's largest.

Teams

This area lets you configure how Jira loads and interprets your estimation data. This will eventually support team-specific settings.

Toolbar

image

Report On

Jira_Timeline_Report

Select what you want to report on. You can select a specific issue type OR select releases and the issue type under that release.

Report Type

image

Select the style of report you want:

  • Gantt with both start and due dates
  • Scatter with just due dates

View Settings

image

View settings let you:

  • Group the report type by parent or by team/project value.
  • Sort the report by the order the JQL specified or Due Date
  • Show or hide issues by a status
  • Show issues within a particular release
  • Hide issues without calculated dates
  • Show a breakdown of child issues labelled with design, qa, or uat
  • Show a percentage completion value
  • Show another status report breaking down each issue in more detail.

Detailed Change Log

New Contributors

Full Changelog: v0.4.6...v0.5.0

Grouping Children

24 Sep 17:04
b3ab09f
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.4.5...v0.4.6

Global Filtering, Grouping, Show Children, New Example Data

23 Sep 02:37
3f5a23a
Compare
Choose a tag to compare

Global Filtering

A new "Statuses to Exclude" filter has been added. This excludes the specified statuses across all issue types.

image

The other "[TYPE] Statuses to Ingore" option only ignores this status on the reported issue types.

Use "Statuses to Exclude" to ignore statuses like canceled that should always be ignored.

Use "[TYPE] Statuses to Ignore" to ignore statuses like done that you might not want to show up in the report.

Grouping

There's an ability to group the report by "Parent" or "Team / Project".

Show Children

The context menu has a link to show the children of the selected issue.

image

New Example Data

Updated the report to use new example data

Updated OIDC redirect build

19 Sep 19:34
b34da18
Compare
Choose a tag to compare

This updates the OIDC redirect build to include everything it needs. This should result in slightly faster redirects.