Analyze release progress and quality

Use an assortment of tools to track a release's progress and quality.

Progress column

View the Progress column for any feature or backlog item. Hover over the progress bar to see more details about a specific item:

Note that ALM Octane measures progress for Epics and Features by story points, and progress for Backlog Items in hours.

View the Progress column in both the Grid View and Smart List View.

Back to top

Planning buckets

In the Backlog module, view the release progress bucket:

In the Team Backlog module, view the Team Progress widget:

In the Team Backlog module, view the planning buckets for each of your team members:

Overview tab widgets

The Overview tab provides a set of widgets with which you can monitor progress and quality aspects of the release.

Use the default set of widgets, or select other widgets from the Widget Gallery. You can also design your own customized widgets. For more details, see The Dashboard.

The scope of the widgets in the Overview tab is set by the context filters at the top of the page, and by the epic or feature selected in the Backlog tree.

Further filter the widget data using the Filter categories in the right pane.

The Runs in Release and Runs in Milestone filters in the right pane impact only test and test run widgets.

Back to top

Release forecast widget

Add the Release forecast widget to the Dashboard module.

This widget displays a line with the forecasted progress of user stories or defects through the end of the selected release. This graph also includes details on the release, including finished story points and expected completion.

ALM Octane displays the forecast line after you mark enough Backlog items as Done.

How is the forecast calculated?

  • The forecast is based on the state of the release’s actual story points until now, together with the planned story points for the team. This is based on the team manager’s expected velocity, as defined in the Team Backlog module. The gap between actual and planned velocity is used to forecast when the release content will be complete, based on the assumption that this gap will remain constant in the future.

    For example, if the expectation to date is 50 points and actual completion is 45, the gap shows that the current pace is 90%. The forecast assumes that at the planned date of completion, 90% of the content will be done.

  • If there is no expected velocity available for calculation, the forecast is based on the assumption that the actual points-per-day rate will remain constant in the future.

What do the colors represent?

  • The solid green line shows actual progress, and the yellow line shows expected velocity as defined by the team leader or equivalent role.

  • If the forecast (dotted) line is green, this means the release content is expected to be done by the release date.

  • If the line is red, the content will not be complete on time, at the current rate of progress.

Where can I see forecasting?

Forecasting is available on Agile graphs, and not on Custom graphs. Forecasting is available for a release, and not for a sprint. You can see forecast data on burn-up graphs only.

If there are too few story points to generate a release forecast, your graph will be empty. Clear the Forecast checkbox to show data in the graph.

Back to top

Feature cycle widgets

ALM Octane provides several Tracking Process graphs to help you track the cycle time for features, quality stories, and user stories. These graphs also have Insight cards which provide you with analytics, showing data that can help you identify correlations, anomalies, trend behavior, and bottlenecks. For details, see ALM Octane insights.

Note:  

  • Versions of ALM Octane preceding CP5 (12.55.8) did not collect tracking data. Therefore, if entities were handled in earlier versions, they will not appear in the graphs.
  • Items with a cycle time of less than an hour for a specific phase, are not included in the phase's average calculation.

Feature cycle time across releases

This trend graph compares the average cycle time of multiple releases. The graph header shows, as a percentage, the increase or reduction in the average cycle time compared with earlier releases. Using this cross-release trend graph, you can see whether you are improving your development cycle with shorter cycle time for features, resulting in less time to market.

When you hover over points in the graph, a pop up provides information about the release, for example, the number of completed features, and the average story points per feature.

By default, cycle time refers to the time a feature was started (In Progress) until its completion (Done). In the Scope page, you can customize the start and end phases from which to measure the cycle.

Feature cycle time by phase across releases

This trend graph shows how long features remained in each phase across multiple releases. The y-axis shows the average number of days that the features remained in each phase. In the Scope page, you can indicate which phases and releases to track.

Study this graph to find patterns in the feature cycle time. This information lets you spot anomalies in the release cycle and pinpoint the problematic phases. When you hover over the different sections of the graph, the tooltips show a summary of the time periods. For example:

In this example, the later release shows a decrease for the In Progress phase, but an increase for the Ready for QA phase for Release 2. In the second release, the time that features waited for QA is higher, which may indicate a shortage in QA resources.

Feature cycle time by phase

This graph is not a trend graph. It is a summary graph that shows how long features remained in each phase. The y-axis shows the number of days that the features remained in each phase. In the Scope page, you can indicate which phases and releases to track.

This widget enables you to select features completed on a specific time frame (not necessary coupled to a specific release) and enables you to drill down to the cycle time of each phase in order to identify bottlenecks.

Back to top

Defect resolution time widgets

ALM Octane provides several graphs to help you track the defect resolution time. These graphs also have Insight cards, which provide you with tips and suggestions on how to interpret and act on the graph's information. An additional insight allows you to determine the quality of defect resolution, by showing a graph of defect resolution time vs. reopen rate. The Reopens field shows the number of reopens for each defect. If it is not showing, use the Customize fields button to add it. For details, see ALM Octane insights.

Note: Versions of ALM Octane preceding CP5 (12.55.8) did not collect tracking data. Therefore, if the defects were handled in earlier versions, they will not appear in the graphs.

Defect resolution time across releases

This trend graph shows how long defects remained in each phase across multiple releases. The y-axis shows the number of days that the defects remained in each phase. In this widget's Scope page, you can configure that start and end phases that you want to track.

Study this graph to find patterns in the defect resolution time. This information lets you spot anomalies in a specific release and pinpoint the problematic phases.

The graph header shows, as a percentage, the increase or decrease in the average defect resolution time, i.e. to the end phase, compared with earlier releases. This information lets you spot issues in the release cycle and pinpoint the problematic releases.

When you hover over points in the graph, a pop up provides information about the defect resolution time.

By default, the defect resolution time refers to when it was created (New) until its completion (Closed). Therefore, if a defect did not reach the Closed stage, it will not be added to the calculation of the average resolution time. In the Scope page, you can customize the start and end phases from which to measure the time.

Defect resolution time by phase across releases

This trend graph shows how long defects remained in each phase across multiple releases. The y-axis shows the number of days that the defects remained in each phase. In the Scope page, you can indicate which phases and releases to track.

Study this graph to find anomalies in the defect resolution time. This information lets you spot issues in the release cycle and pinpoint the problematic phases.

In the following example, although a reduction in the resolution time occurred for Release 2, there was an increase for Release 4. specifically in the Pending Support phase. This indicates that the handling of this defect by support was a bottleneck in the development cycle.

When you hover over points in the graph, a popup shows how long the defects remained in each phase, at the selected point.

Defect resolution time by phase

This graph is not a trend graph. It is a summary graph that shows how long defects remained in each phase. The y-axis shows the number of days that the defects remained in each phase. In the Scope page, you can indicate which phases to track.

In the following example, it is evident that the defects remained in the Rejected phase for longer times than any other stage.

Back to top

Next steps: