Estimating in Scrum is a broad subject but it has already been well described and I think it is also well understood. However, there are some areas where I still observe tendencies to do it wrong. One of them is estimating bugs.
To make my opinion absolutely clear - I strongly think that estimating bugs in Story Points is wrong when you do Scrum. This is not just an opinion. I have good reasons to not do it. Let me show you what would happen with your Scrum if you decide otherwise.
Estimating bugs is extremely difficult
This reason appears the most often in Agile articles. Imagine a bug described like this:
Steps to reproduce:
1. Choose user Tom.
2. Type 10 in the Amount field.
3. Click Submit.
Current result:
Blank page. 10 is not added to the account.
Expected result:
Confirmation message. 10 added to the account.
How many Story Points should be assigned to this bug? You have no idea? Me neither. I have to check the logs, debug it, analyse the flow. Probably confront it with documentation. Then fix it. I have no clue how much effort is needed. I do not even know how much time I need for analysis. It could be one hour or a week. I am talking about time on purpose to make the difficulty even more visible, but Story Points do not make it easier.
If somehow I already know what is the source of the problem, the fix will be quick in most cases. Probably better to fix it immediately instead of creating an issue in a bug tracking system, estimating, planning etc.
If it does not convince you because you think but sometimes I know the estimate so can I put the number of Story Points to Jira?, keep reading this article and I will explain you why you should not, even in such case.
More work with buffers
When you consider starting a project, you create epics and stories. They get estimated in Story Points. Lets assume the whole project is estimated to 100 SP (Story Points). You know that the team velocity (a number of Story Points done in a sprint) is 10 SP/sprint so after 10 sprints (100/10) the project should be completed.
Good way
If you do it right and do not estimate bugs, any bug found is fixed without adding any Story Points to the team velocity. No matter how many bugs are found, the project is still 100 SP and is completed in 10 sprints as the velocity already contains a buffer for bugfixing as there were bugs in the previous project as well.
Bad way
If you estimate bugs, the team velocity is 12 SP/sprint so it seems like 8-9 sprints should be enough to complete the job. Unfortunately, the initial project estimate grows from 100 SP to 120 SP for example, but you do not know it upfront. At the beginning it seems to be 100 SP, in the middle of the project there are bugs and stories for 110 SP in total (completed + uncompleted), at the end there are 120 SP. If you want to make it somehow predictable, you start adding buffers to the estimates. For example, developers estimated effort to 100 SP so you add 20 SP extra to cover bug fixes. It makes sense until you realize that you have to somehow calculate a size of the buffer. Is it 10, 20 or 50 SP? The only way to get a realistic number is to look at the previous projects and see how much the scope grew, calculate the percentage and add proportionally to this project ... uff. It seems like a lot of work on gathering data and doing the math. If you do it correctly, the result is the same 100 SP of the estimate plus 20 SP of buffer gives 120 SP. As the team has velocity 12 SP/sprint, you know the project should be done in 10 sprints.
The result is the same, but you do not let Scrum to take care of the buffer. You have to add it on your own.
Why you may think you need to estimate bugs
1. I need an estimate to decide on the bug priority (or fix vs do not fix).
First of all, estimating bugs is very difficult and even if you think it is 2 hours work, it still might take a week. These estimates are unreliable.
Second, this is not how it should work. Prioritization of bugs should be done based on their severity, impact to the clients, existence of workaround etc. Critical bugs should be fixed as soon as possible, end of story. Their estimate is not important. Business impact is what matters in bug prioritization, not the effort needed to fix the bug. Cost is an important factor for features not defects.
2. I want to know how much time we spent on fixing bugs vs developing new features.
There is another misconception. Story Points in Scrum are used for estimating issues BEFORE the work. It does not mean a 1 SP story took a half of the time of 2 SP story. If you need such data, use a time tracking system. Most companies have a separate application to log work time of their employees. This is a source of such data.
Summary
Estimating bugs in Story Points is against Scrum practices. I have not found any good reason to do it but as described above, there are some to not do it. It is not optional, if you want to have benefits of doing Scrum, you cannot allow bending Scrum rules.
Interested in estimating in Scrum? This article may interests you - high level estimating in Scrum.