Or inconsistency in how bugs are reported and tracked. Or variations on what is considered a "bug". Or huge natural differences between fe and be teams, same with customer facing vs internal facing products.
if it's a small bug, I think it's not a good metric to trace.
But if it's an "incident", IMHO, it is worth to track. So that you can see how much revenue loss due to those incidents, Is there customers affected, and which team/service are responsible for. And if it happens too often, the question goes to team manager, is the timeline too tight, do they sacrifice quality for shipping fast? any internal issues in team. or maybe it's a department issues, maybe not a team-level issues.
The more incidents we have, the more revenue we lose, and the more we damage customer trust.
Bugs found - yes. Maybe not to the team level but to the functional area.
Severity is also tracked, as a grammar error is not as bad as blue screen.
This should be used to identify where more resources need to go to prevent future problems. If it is used to punish then you will get other issues of the blame game.
7 comments
[ 2.9 ms ] story [ 26.4 ms ] threadBut if it's an "incident", IMHO, it is worth to track. So that you can see how much revenue loss due to those incidents, Is there customers affected, and which team/service are responsible for. And if it happens too often, the question goes to team manager, is the timeline too tight, do they sacrifice quality for shipping fast? any internal issues in team. or maybe it's a department issues, maybe not a team-level issues.
The more incidents we have, the more revenue we lose, and the more we damage customer trust.
Severity is also tracked, as a grammar error is not as bad as blue screen.
This should be used to identify where more resources need to go to prevent future problems. If it is used to punish then you will get other issues of the blame game.