I like the idea of introducing the Weights. The need of the origin would still be needed. Let me explain in a bit. From my experience of managing teams, I look for ways to praise my team too. For example, if the design bug has caught in the development phase but not in the design phase, it needs significant rework but rework would still be less then when a bug caught in the SQA or the PROD phase. Did you see the idea? I'm fine with bug until they are found early enough in the development lifecycle. Finding a requirement or a design level issue late in the game may warrant a lot of rework or lead towards the product or a feature failure.
For large products, origin help with identifying a right team (could be design team or any other team) for fine-tuning to uplift the product quality.
Need to see, how we may expand the Weights on origin in terms of the level of effort; it usually takes longer and hard to fix design or requirement level bug while sitting in prod.
Ahh, I see the inherent difference between our teams! I can agree that origins would be crucial for yours, since you have different Design, Coding, and SQA teams. By contrast, at my company, one team covers the entire process.
I can also see how origin might be useful to my team in limited situations, but in general, we don't have the time to figure out origin on every bug.That aside, I'll make room in my bug tracker for an optional origin field.
As to weights, if I'm understanding this, the longer a bug lives, the higher the score it needs, yes? If so, it's actually pretty simple, although I can't really set up the table here.
Using the same multipliers...
| | Req | Des | Code | SQA | Prod | Total |
| MULT | x0 | x0 | x1 | x2 | x3 | |
If a bug is caught in Prod (3), and origin at Code (1), then SCORE = CAUGHT - ORIGIN = 3 - 1 = 2.
Similarly, if a code is caught in Prod (3) and origin at Design (0), then 3 - 0 = 3.
I like the idea of introducing the Weights. The need of the origin would still be needed. Let me explain in a bit. From my experience of managing teams, I look for ways to praise my team too. For example, if the design bug has caught in the development phase but not in the design phase, it needs significant rework but rework would still be less then when a bug caught in the SQA or the PROD phase. Did you see the idea? I'm fine with bug until they are found early enough in the development lifecycle. Finding a requirement or a design level issue late in the game may warrant a lot of rework or lead towards the product or a feature failure.
For large products, origin help with identifying a right team (could be design team or any other team) for fine-tuning to uplift the product quality.
Need to see, how we may expand the Weights on origin in terms of the level of effort; it usually takes longer and hard to fix design or requirement level bug while sitting in prod.
Ahh, I see the inherent difference between our teams! I can agree that origins would be crucial for yours, since you have different Design, Coding, and SQA teams. By contrast, at my company, one team covers the entire process.
I can also see how origin might be useful to my team in limited situations, but in general, we don't have the time to figure out origin on every bug.That aside, I'll make room in my bug tracker for an optional origin field.
As to weights, if I'm understanding this, the longer a bug lives, the higher the score it needs, yes? If so, it's actually pretty simple, although I can't really set up the table here.
Using the same multipliers...
If a bug is caught in Prod (3), and origin at Code (1), then
SCORE = CAUGHT - ORIGIN = 3 - 1 = 2.Similarly, if a code is caught in Prod (3) and origin at Design (0), then
3 - 0 = 3.Like that?
Ahh, what a math!
Yes, the longer a bug lives, the higher the score
I don't know if I ever told you, but I absorbed this idea into Quantified Task Management: standards.mousepawmedia.com/qtm.html
I also talked about it here recently: legacycode.rocks/podcast-1/episode...