When you have to decide if a product is ready for release (in terms of quality), you can use Bug Trend reports to provide a visual representation of how many new bugs have been opened, empowering you to make an informed decision.
Using Custom Graphical Reports, it is possible to build a report that shows New Bugs added into Projects, grouped by week and colored by Severity:
Here is an example of the settings for one such report:
With slight modification it is also possible to analyze Closed Bug trends. This report shows Bugs fixed by Releases.
Here, we took the report based on New Bugs and replaced StartDate with EndDate and grouped by Release instead of weekly throughout a Project's lifecycle. We also switched from a Stacked Bar chart to a Line graph.
In order to compare multiple trends you can add both reports to the same Dashboard. Or, use the (older) Bug Dynamics report which will show you everything in the same place but does not support flexible filters and grouping.
Open Bugs Weekly by State and Project / Release
It is possible to colorize Bugs according to their current State.
Here is how to create such report:
Instead of X: Project it is possible to split bugs by X: Release.
To get amount of closed bugs use Week(EndDate). However in this case all bugs will be in Closed state. Use Color feature for some other property but EntityState.
In order to exclude closed bugs from this report, use the following main filter for Bug data source:
?CreateDate >= Today-3(months) and EntityState.isFinal is false
Bug Dynamics Report
This legacy Targetprocess v2 report shows the breakdown of bugs by state for a project, including state changes over time. Using this report you can make an informed decision about whether a product is ready for release. For example, if too many bugs have been opened lately, the release may not be ready for deployment.
This report is found in Reports → Other Reports → Quality Assurance → Bugs Dynamics.
You can also group the info by days, weeks and months:
In the non-project management world, sparkline graphs work as quick time-span mini-reports featuring the dynamics of certain states or activities. The sparkline graphs usually look like tiny ragged lines.
Sparkline charts can be added to Project card and Team card within Customize Cards feature.
Here's the logic behind the sparklines for user stories and bugs:
Any sparkline covers a time span of 16 weeks. Why 16 weeks? It's convenient in terms of iterations and releases, as in agile project management iterations usually take 2 weeks. So, this stands for ~ 8 most recent iterations. If you count each tiny sub-bar, this would total to 16 (in the sparkline for Designers and Philadelphia Flyers teams. The Support team has less than 16 weeks history, most likely). The 16 weeks time-span seems to be working well for iterationless development, too, as in Kanban.
The zero line is the vague blue line in the middle (or, the red one, for bugs).
The actual numbers shown on the top and on the bottom represent the max. number of user stories done or added, respectively, at any given week out of those 16. If you see the max. number, for a week that goes shortly after the 4th week, then you get an idea of how many user stories have been done in the previous or in the following weeks. There's no need to show the numbers for each week, as it would make this tiny graph too clogged. The same logic stands true for bugs.
The numbers on the very right, in the sparkline, relate to the current week.
The "total" numbers show how many user stories were done in those 16 weeks (on the top) and how many were added (at the bottom). Sames for bugs: the total fixed number is on the top, and the total added — at the bottom.
If you're a stakeholder, or a Scrum Master, or VP of Development, or anyone who wants to keep an eye on how those several teams are doing, this report is indispensable. With the least time spent, you get the maximum info. And - yes - there's no recency bias. You are able to embrace the whole span of 16 weeks in that little space.
It's not only about the counts of bugs and user stories. For example, if you see that your sparkline for user stories is keeping low, close to zero, and your bug numbers are pulsating with action, this means that this team is currently working to make the release stable (most probably).
Finally, this logic which has taken me quite a bit of space to explain here, is condensed to a mouse-over text tooltip.