Download reports

Click Download to display the download dialog.
Enter a name in the
YOUR FILE NAME
field. All other fields are pre-populated.
Click
Download
to download the report or
Cancel
to cancel the download.

Widgets

Development activity

The displayed data is governed by the date range selected from the timeframe in the header,
Select Duration
, default
7 Days
.
Dashboard filter
Applications filter
Defect
or
Issues
Category, dropdown menu located on the right above the displayed widget. For each category there are three status option to display data in the widget:
New
Updated
Closed

The X-Axis (Number of activities):
The X-axis corresponds to the dates within the activity's timeframe.
The Y-Axis (Timeline):
The Y-axis corresponds to the number of new, updated, or closed defects or issues for the selected timeframe.

Applications

Defects and issues status

New Defects:
Provides a view of bugs discovery rate. This trend helps the development manager to understand the growth of new bugs, which is critical for new features. A spike might indicate a problematic release or a specific area of the application that needs attention. If the trend shows a consistent number of new bugs, it might indicate that the team is not addressing the root causes of these bugs.
Updated Defects:
Displays a visibility of bugs that are being processed. These are the bugs that are in different categories like active or test etc. Comparing different applications will help development managers to identify which team is focusing on working on bugs.
Closed Defects:
Displays bugs that have been closed during the selected duration. The development manager can relate the trend of closed bugs with each release. If the number of closed defects increases after a release, it might indicate an initial instability that is being addressed. Conversely, a steady decline in closed defects over time can suggest that the application is becoming more stable. By comparing the trend of closed defects with the trend of new defects, you can manage your defect backlog more effectively. A higher rate of closure compared to new defects indicates a reducing backlog.
New Issues:
The trend in the bottom right captures the information of the newly created epics and user stories. An ideal way to visualize this is monthly. Depending on the sprint planning activities, usually this should be higher at the Sprint planning phase. This can be correlated with the sprint schedule.
Updated Issues:
Displays those issues that have changed its status. These issues can be user epics and user stories that the engineering team is currently processing. This should again follow the sprint cycle as it should reduce the time sprint ends. The right graph (Applications) gives an application level breakup, which should also account to the similar split in the team structure. The development manager can improve the team allocation based on the updated issues of the applications.
Closed Issues:
Displays the rate of closing epics and user stories. Consistent closure of features indicates a well-functioning team, while fluctuations might highlight areas that need attention or improvement

Technical Services table

Technical service:
The name of the micro technical service within the larger application.
Application:
The application's name typically comprises multiple micro-technical services.
New defects:
The number of new defects opened against the technical service during the selected time.
Updated defects:
The number of open defects against the technical service that have been updated during the selected time.
New issues:
The number of new issues opened against the technical service during the selected time.
Updated issues:
The number of open issues against the technical service was updated during the selected time.
Active PR:
Active Pull Requests.
Tool engine:
The name of the technical service that produced the issue or defect ticket, such as Git.

Defect and Issue Summary:
This comparison displays the trend of new vs updated vs closed bugs during a specific period of time. By comparing the trend of closed defects with the trend of new defects, you can manage your defect backlog more effectively. A higher rate of closure compared to new defects indicates a reducing backlog. Similarly, it also compares the trend of issues together for new vs updated vs closed.
Detailed view of Issues and Defects:
Above the Defects and Issues graph, is a Defects Summary and an Issues Summary containing the number of anomolies (New, Updated and Closed Defects and Issues). Each number is a clickable hyperlink that displays a drill-down view of that item. Tag searches also available.
Pull Request and Commit:
These two charts capture the information on the trend of how commits and pull requests are progressing. This data is captured from GitHub for the repo you have selected in the Technical services page. The metrics illustrate the development activity within the specified repository. The closed trend indicates how many pull requests have been approved and merged into the main branch. Ideally, there should be a balanced flow between the number of new pull requests and the number of closed pull requests.
The commit trend reflects the level of development activity in the repository. Regular commits contribute to effective branch management, keeping the codebase up to date and reducing integration conflicts.
Details of Pull Request and Contributors:
The details page of a pull request provides an overview of the number of open PRs for the selected repository. The updated date indicates the age of each PR, allowing managers to see which parts of the codebase are pending review and for how long. This capability offers insight into the review efficiency of the application. The PR link directs to the GitHub page, where development managers can monitor and review progress and identify any delays. If the number of open PRs is high for a specific repository, appropriate intervention might be necessary to prevent delays.
Contributor details are specific to the selected repository and time frame. This information shows how much a developer has contributed in terms of lines of code changed and the number of commits. It also indicates the size of PRs, which should be managed to ensure an effective review process.