We are using two Separate bug tracking tools (one for the core product and one for customisations). We want to merge them together because
1) we are finding that our customers need fixes before our core dept gets them merged into the core product
2) many bugs are fixed in the core product and our customers have not or choose not to upgrade. Often they don't know which build has the fix.
3) there is duplicate effort in both departments
Both teams are using Scrum
Bug trackers have moved from mainly tracking simple tasks to much more sophisticated software that can do things like managing the project lifecycle, creating custom workflows and offering greater reporting to improve future planning work and many more activities. Bug trackers have extended beyond the domain of just programmers.
We are using two Separate bug tracking tools (one for the core product and one for customisations). We want to merge them together because
1) we are finding that our customers need fixes before our core dept gets them merged into the core product
Answer: Using Business Rule Requirement it can be resolved - (Core Product Rule 1 & 3 matches with customization on #1). if we do this all the rules will be covered and provide this Excel to Client that it has been verified in this Product release version 1.0.2
2) many bugs are fixed in the core product and our customers have not or choose not to upgrade. Often they don't know which build has the fix.
Answer: Whenever Product release has happened the excel should be sent to clients and which should have the bug status of deferred means that it will be taken care in next version upon you confirmation in the logic or functional flow etc... this makes the customer to confirm from their side to do quality deliverables from us.
3) there is duplicate effort in both departments
Single excel to keep hyperlink on first worksheet of Core Product BR's # and click will navigate to second worksheet of customization rules 1, 2, 3... time will be less...on verification
You may get client appreciation too ....
without more context, my advice is to declare blankrupcy. Just throw away one of the systems, preferably both, and start over. Entering the bugs you are currently working on in a new system.
If you get problem report from the field you could look it up in the old systems to see if it is known, then add it to the new system. The point is the old systems have bugs you Ain't Gonna Fix Unless Something Changes (AGFUSC), and the SC woudl be "another complaint from the field", so re-enter it.
Ron Jeffries has an interesting article on this called petition the king that he uses to extend to even include new features!
http://xprogramming.com/articles/petitiontheking/
without more context, my advice is to declare blankrupcy. Just throw away one of the systems, preferably both, and start over. Entering the bugs you are currently working on in a new system.
If you get problem report from the field you could look it up in the old systems to see if it is known, then add it to the new system. The point is the old systems have bugs you Ain't Gonna Fix Unless Something Changes (AGFUSC), and the SC woudl be "another complaint from the field", so re-enter it.
Ron Jeffries has an interesting article on this called petition the king that he uses to extend to even include new features!
http://xprogramming.com/articles/petitiontheking/
We are using two Separate bug tracking tools (one for the core product and one for customisations). We want to merge them together because
1) we are finding that our customers need fixes before our core dept gets them merged into the core product
Answer: Using Business Rule Requirement it can be resolved - (Core Product Rule 1 & 3 matches with customization on #1). if we do this all the rules will be covered and provide this Excel to Client that it has been verified in this Product release version 1.0.2
2) many bugs are fixed in the core product and our customers have not or choose not to upgrade. Often they don't know which build has the fix.
Answer: Whenever Product release has happened the excel should be sent to clients and which should have the bug status of deferred means that it will be taken care in next version upon you confirmation in the logic or functional flow etc... this makes the customer to confirm from their side to do quality deliverables from us.
3) there is duplicate effort in both departments
Single excel to keep hyperlink on first worksheet of Core Product BR's # and click will navigate to second worksheet of customization rules 1, 2, 3... time will be less...on verification
You may get client appreciation too ....
Bug trackers have moved from mainly tracking simple tasks to much more sophisticated software that can do things like managing the project lifecycle, creating custom workflows and offering greater reporting to improve future planning work and many more activities. Bug trackers have extended beyond the domain of just programmers.