3 ms·
I'm going to add to the pile-on that the "Ticket Type" field is a little more useful than the author gives it credit. > why do you want to have this informatio
by cdcarter 6y ago
I'm going to add to the pile-on that the "Ticket Type" field is a little more useful than the author gives it credit.
> why do you want to have this information and what is it going to be used for?
You might say this is yet another proxy for priority, but it's slightly more nuanced than that. A lot of software companies do not have the experience of continuously deploying the main code branch. I work on a SaaS solution that's gained traction in highly regulated industries.
It's very useful to be able to identify (trends in!) bugs that could be described as a "regression" or breakage in behaviors that customers are known to rely on. This isn't the example of "Customers" from your post though, ultimately how the change gets prioritized and released is what they care about! This is about being able to identify and systemically manage change in high risk areas.
- taftster 6y agoMost if not all software is shipped with known defects. So clearly, the fact that a "bug" can be identified doesn't give any weight when describing when it needs to be fixed. A missing feature can be just as onerous to a user as a defect. Understanding if an issue gets in the way of productivity is all that matters, regardless if it's described as a bug or a feature. Tracking metrics against bug vs. feature is a surefire way for a system to be gamed. If there are consequences in finding/reporting defects, then all work-items will eventually be labeled as "features". Or if you reward finding bugs, then all work-items will gravitate towards "defects". It's up to you how you want to play this game.
- Almad 6y agoFair, although, depends on scale again. As they say, at scale, every implementation detail is something customers rely on :)