In general tickets describe change requests, and they are sometimes referred to as such (CRs): Someone wants the software/system to change in some way.
A ticket type makes sense because bugs and new features are not the same and we should care about the difference. A bug is a defect in the implementation of a feature that should be fixed. A good practice is to fix defects before adding new features, as far as possible.
A defect is discovered on a specific software version so it then makes sense to indicate that. Even with continuous delivery it is useful to know exactly what build exhibited the issue.
Having explicit information on whether a ticket is a defect or a new features is also helpful for QA (as is severity): I need to keep track of the number of defects found in order to somehow measure the quality of my software and of my testing and to improve it.
Assigning a priority makes sense because it helps setting the ticket's position in a queue (which can be called TODO list).
Severity is not the same as priority. Severity is the impact of a defect. A defect that causes the application to crash and delete all data is very severe. A typo is likely not a severe defect. Again that helps in assigning a priority and thus how to insert the ticket in the TODO list.
The position in the TODO list is not an input it is an output of the task that consists in analysing and managing the pending tickets.
You could say that a dev is a worker task that picks the next ticket in the TODO list in a loop, while a (project) manager manages the tickets and insert them in the TODO list.
This analytical approach is exactly what I disagree with.
> A good practice is to fix defects before adding new features, as far as possible
This is the approach I describe as "bug is a proxy for priority", where you are essentially saying it's "highest". It is a good approach in theory, but just ignores business realities.
It also means people will try to disguise feature requests as bugs in order to get a priority.
> Assigning a priority makes sense because it helps setting the ticket's position in a queue
Except if it's numerical, then over time, you can safely ignore everything that's not P1 and you have few dozens/hundreds of unprioritized tickets.
> Severity is not the same as priority.
I know. Why is it important to make the distinction though?
> The position in the TODO list is not an input it is an output of the task that consists in analysing and managing the pending tickets.
Agreed.
> You could say that a dev is a worker task that picks the next ticket in the TODO list in a loop, while a (project) manager manages the tickets and insert them in the TODO list.
Well, if dev is a factory worker turning inbound tickets into outbound features, yeah, cool, this works.
I am yet to see this in practice. Team (or at least team lead) is taking active role in the managing cycle and this is exactly what renders a lot of your points at least duplicit.
(But you have a lot of good points about assumptions about team organization that should be mentioned)
> It also means people will try to disguise feature requests as bugs in order to get a priority.
If my car breaks and cannot start, that's a bug. If I want to add a radio to my car, that is an extra feature. The difference exists, and it is important. You are saying this difference should be ignored because someone may try to pass the desire for a radio as a broken car. At that point, you could just ignore any issue because it may be a lie.
And the reason to categorize is not only to prioritize. For example, we have these rules: bugs require of a test case, and the test must pass to consider close the bug. On the other hand, new features are implemented first in a different tree, and the new feature needs to be documented (also in the tutorial). Moreover, we may have meetings to decide if we add a feature or not (for example, different new features may not work well together or may require extensive refactoring that we do not want to do), while a bug must be fixed.
In your workflow, this distinction may not be important. That's perfectly possible. But, in my opinion, claiming that "we collectively shouldn't care" is going to far (unless "we collectively" means something more specific than it looks to me).
This analytical approach is the reality of managing tickets taking technical and business realities into account.
A bug is not a proxy for priority. As said it is a parameter that helps defining a priority and, in fine, the position in the TODO list.
Whether priority is "high", or P1, or whatever is exactly the same. Usually there no need for too many levels because, as you suggest, it mostly boils down to "now", "afterwards", "whenever", and that changes over time (hence Agile ideas).
BTW, I have never seen someone disguising a feature request as a bug. That is totally unrealistic not least because obviously this is continuously scrutinised and someone doing that would be called out and ultimately fired for shear incompetence (or worse) and because features go through a definition process, it's not someone who suddenly dreams one up and sneakily hide it in a bug report to have it implemented without anyone noticing (what?!)
The distinction between severity and priority is important. Severity is assigned by the person who reports a defect. It is a measure of how serious the impact of the defect is, as said. Priority cannot be set at that point, as it is a judgement made later based on further considerations.
Devs really are as I described in teams that have matured and are organised (but maybe not in "messier" startups). A team lead is not a dev, 'lead' implies a managerial aspect.
Lastly, of course you need to keep track of the number of defects (which can be from customers feedback and production metrics) and of their severity. This is basic QA, you have to know if you are effectively doing a good job in order to improve both your internal processes and the quality of your product.
For example, if I start to see too many critical defects on a component/team I know we have a problem there. If I start to see too many critical defects found after the product has shipped I know we have a big problem.
I'd agree with you if I would be only seeing the teams through my management reports and not from the trenches.
I am envious of the environment where you never saw somebody trying to bug feature request as a bug. I do think in a lot of cases, it's a judgement call...or a habit where problems perceived as bugs by customers are swung under the carpet as features as bug is only defined as "deviation from requirements".
Fair on distinction of severity by customer vs priority by team, although I am used to make a distinction between support ticket by customer and issue in engineering team's queue.
Lead implies either managerial or technological leadership and especially in mature organisations, I've seen both.
My experience with management by bug statistics is...very inconsistent as it motivates people to game the system...and boy I've seen that a lot. I do agree trend knowledge helps, but I am not sure it's worth the side-effects and work.
Of course, a flavor of this depends on context (and scale). It is very different if you have a single-instance SaaS, distributed system or images shipped to air-gapped systems.
> I am envious of the environment where you never saw somebody trying to bug feature request as a bug.
Really, I have never seen that in 20 years.
Of course that is different from another team or the test team raising a bug because they expected something that was not in the spec. Then you tell them that it's not because it does not behave the way they want that it is a bug.
But, yes, a defect (more general term than bug) is any deviation from requirements.
Direct input from customers is different as well. Unless there is a contractual impact, if a customer is adamant something is a bug when it technically isn't then there is no point arguing. You can treat the request however you want internally.
About the only thing I might add is dependencies. But even that is mostly value for management reporting and time estimation. It doesn't help the workers do their jobs that much.
A ticket type makes sense because bugs and new features are not the same and we should care about the difference. A bug is a defect in the implementation of a feature that should be fixed. A good practice is to fix defects before adding new features, as far as possible. A defect is discovered on a specific software version so it then makes sense to indicate that. Even with continuous delivery it is useful to know exactly what build exhibited the issue. Having explicit information on whether a ticket is a defect or a new features is also helpful for QA (as is severity): I need to keep track of the number of defects found in order to somehow measure the quality of my software and of my testing and to improve it.
Assigning a priority makes sense because it helps setting the ticket's position in a queue (which can be called TODO list).
Severity is not the same as priority. Severity is the impact of a defect. A defect that causes the application to crash and delete all data is very severe. A typo is likely not a severe defect. Again that helps in assigning a priority and thus how to insert the ticket in the TODO list.
The position in the TODO list is not an input it is an output of the task that consists in analysing and managing the pending tickets.
You could say that a dev is a worker task that picks the next ticket in the TODO list in a loop, while a (project) manager manages the tickets and insert them in the TODO list.