There's no one right answer.
In fact, estimating bugs is a tricky business. What is often the case in my projects is that if we don't estimate, we assign story points for the actual effort afterwards.
This helps especially for evaluating afterwards how much % of the sprint was spent on bug fixing. This tends to help in planning future sprints (especially if the defect rate does not fluctuate too much). And on the other hand, it is a good indicator of the quality of the product, but also of the process. In Continuous Deployment environments it directly shows a correlation to the product quality. In Non-Continuous Deployment environments it is a good indication where weaknesses are in the development process. For example, if despite elaborate unit tests, mockup tests, etc., it turns out during integration that unexpected errors occur during E2E testing. In retrospectives, the focus can then be specifically directed to this.
In my current project, we already estimate the defects with storypoints before fixing them. Of course, this is more or less successful (see reasons of the questioner), but it is still better than not planning with them at all.
Well, to what extent it's economical I think also depends a bit on how much time you invest in estimating. Estimating bug fixes is more difficult than estimating user stories.
It requires more of an understanding of what has already happened in the code, and user stories are more about producing new code and embedding it into existing code. Identifying a bug as such can also take time. It may also have been a bug in the specification and you could turn it into a change request, which would then also be easier to estimate.
Bug fixes are a quest and how economical it is can therefore, in my view, depend heavily on how well the developers already know the code. I personally am not a fan of estimating bugs with story points either.
If you decide to do so, days, hours could help to have a better feeling for the sprint planning, you have to somehow plan how much time is left for other items besides the bug.
Assigning story points to a bug somehow distorts the velocity and creates a feeling of, we have given so much value. But a bug is a bug of a feature for which there were already story points and do I really want to reward a bug with an increasing velocity? So what would really be economical for me would be more finding the root causes of the bugs and fixing them. That could be too frequent personnel changes or not enough domain knowledge. Training, story swarming, better testing or pair programming could be appropriate approaches, for example.
In the teams I've worked with, bug fixing tasks are also valued. An easy bug to fix is quickly appreciated, a tricky one often not appreciated at all. That's why we work with
lightning analyses, if our support cannot reproduce a bug. Thereby
the developer invests a maximum of 30 minutes and promptly and often
he sees with a few glances how severe the bug is.
Analysis stories: Bugs that cannot be estimated in the refinement
because the cause is unclear even for developers are analyzed via a
storypoint-limited user story. If the bug can be fixed quickly, then
this is of course done immediately. If the analysis or the bug fix
requires more time than the agreed (1, 2?) story points () then the
story is aborted and the intermediate result is communicated. The
Story Points are defined once as a rule of thumb. For us 2
.