Some thoughts about bug tracking.
Low priority bugs
Leave low priority tickets for new comers — such bugs let you show internals of your product doing something useful. Among such issues are all simple kinds of work with text (for example, fixing typos).
Underestimated issues
Find the issues that have required much more time than it was estimated (2-3 times and more) — it can mean, that the developer who worked with it faced something unusual, so he can share the experience gained with the rest of the team.
Bugs on paper
Make sure you (or your developers) don’t keep a list of bugs to fix on the sheet of paper. We do it due to the fear of appearing as non productive developers, right? Just don’t do this. Report them.
Developer ratio
There are plugins to bug tracking systems (I saw such one for Jira) that calculate under/over-estimate ratio for every developer, i.e. how much is the difference between the estimate and actual spent time amout. This ratio is multiplied by all further developer’s estimates, so that his manager can find out how much the real estimate is (most adequate developers have this ratio equal to 1, of course). If you show the ratios to the developers, their estimates could become more accurate.
By the way, do you know that appeared in Star Wars? 
Recent Comments