4 ms·

It's not really a lie when you think about it. It's very true to its name. It's saying, after you've classified the bugs, you're not to do any other work until

It's not really a lie when you think about it. It's very true to its name. It's saying, after you've classified the bugs, you're not to do any other work until the bug list is cleared. This will lead you to zero-bugs (of the known ones of course). I've implemented and seen this first-hand in 4 different companies.

Dylan16807 10y ago
That's not the part I'm calling a lie. Let me word it differently. You classify tickets into categories A,B,X,Y. You always clear out A and B before doing anything else. As a strategy to have "zero unresolved important issues", it's valid. The disconnect is between the "Bug" ticket category, and the actual definition of what a bug is. "Web font is being downloaded when it should be embedded in the app" is clearly a bug, by the normal definition of bug. This system classifies by priority to get Critical/"Bug"/Other, and it further divides the lowest priority into new features vs. changing features. At no point does it ask if something is a mistake. It doesn't care. So it shouldn't use the word 'bug'. It tricks people into thinking it's something it's not.
- samhatoum 10y ago
  Actually this is where you can be flexible with a specification. If the ticket was initially specified as embedding the fonts, then technically it's an implementation defect since it was already specified. However, as a team you might decide it's not too bad to download fonts instead of embedding them. This is where you can be flexible with the solution. Instead ob being rigid with expectation when the reality is the bug can comfortably be re-classified. If however the loading time with downloading the fonts is something the team is not as per the team's quality standards and they are not willing to live with it, then it should absolutely remain as a bug. Now that the classification portion is out of the way, the team priority is to work on bugs first no matter what. So I'm saying that "the actual definition of what a bug is" should be stated as a guideline and the team can decide on an ongoing basis. Some guidelines might be rigid, others not so much.
  - Dylan16807 10y ago
    You can make whatever categories you want. But if your definition of "bug" is in disagreement with the rest of the world, don't tout it as having "zero bugs". Just pick a different word, one that doesn't mislead.
    - samhatoum 10y ago
      I don't think the world has an agreed definition of a bug, or at least I've not seen it! I understand that the issue people have is with the wording of the zero-bug. As I've mentioned elsewhere it's still true that it is a striving towards zero-bug and I've seen it first hand where we get to 0 known bugs. I'll meditate on this a little and see what I come up with. I really do appreciate this feedback :)
      - Dylan16807 10y ago
        Definitions very somewhat, but I think very few people would say that the business impact of a problem changes whether it's a 'bug'.

Dylan16807 10y ago

That's not the part I'm calling a lie. Let me word it differently. You classify tickets into categories A,B,X,Y. You always clear out A and B before doing anything else. As a strategy to have "zero unresolved important issues", it's valid. The disconnect is between the "Bug" ticket category, and the actual definition of what a bug is. "Web font is being downloaded when it should be embedded in the app" is clearly a bug, by the normal definition of bug. This system classifies by priority to get Critical/"Bug"/Other, and it further divides the lowest priority into new features vs. changing features. At no point does it ask if something is a mistake. It doesn't care. So it shouldn't use the word 'bug'. It tricks people into thinking it's something it's not.

samhatoum 10y ago
Actually this is where you can be flexible with a specification. If the ticket was initially specified as embedding the fonts, then technically it's an implementation defect since it was already specified. However, as a team you might decide it's not too bad to download fonts instead of embedding them. This is where you can be flexible with the solution. Instead ob being rigid with expectation when the reality is the bug can comfortably be re-classified. If however the loading time with downloading the fonts is something the team is not as per the team's quality standards and they are not willing to live with it, then it should absolutely remain as a bug. Now that the classification portion is out of the way, the team priority is to work on bugs first no matter what. So I'm saying that "the actual definition of what a bug is" should be stated as a guideline and the team can decide on an ongoing basis. Some guidelines might be rigid, others not so much.
- Dylan16807 10y ago
  You can make whatever categories you want. But if your definition of "bug" is in disagreement with the rest of the world, don't tout it as having "zero bugs". Just pick a different word, one that doesn't mislead.
  - samhatoum 10y ago
    I don't think the world has an agreed definition of a bug, or at least I've not seen it! I understand that the issue people have is with the wording of the zero-bug. As I've mentioned elsewhere it's still true that it is a striving towards zero-bug and I've seen it first hand where we get to 0 known bugs. I'll meditate on this a little and see what I come up with. I really do appreciate this feedback :)
    - Dylan16807 10y ago
      Definitions very somewhat, but I think very few people would say that the business impact of a problem changes whether it's a 'bug'.