In my organization, we do not assign story points to bugs. Some members of my team argue that bugs should slow our Sprint velocity, in order to create an incentive to avoid technical debt and to produce high-quality code. Others, however, argue that some bugs cannot be avoided, and should be reflected in the velocity of a Sprint and in planning meetings. In the collective experience of StackExchange, what is the best practice around assigning story point values to bugs?
Yes, you should estimate points for bug fixing work
There are a variety of reasons for bugs to be found in code, many beyond the control of the developer.
However, there is an exception to the above rule. Do not assign points for bugs found by testers within the Sprint.
In my projects, if the developer worked on a feature and testers found problems, the developer is required to fix them as part of the original estimate. This is to encourage quality coding and avoid slapdash work. We not only do not assign points, we also encouraged the developers and testers to work together and avoid even writing bug tickets for bugs found and fixed within the Sprint. If an intractable bug could not be fixed and had to be carried to the backlog, then we wrote a bug ticket for that. It will be estimated and prioritized as part of the backlog refinement work.
Velocity has one use in Scrum, that is to give the team a means of estimating their capacity for future sprints. It is not a measure of work done, nor should it ever be used as an indicator of the performance of a team.
Imagine a situation where the team is using the velocity as a part of release planning to estimate what can be achieved by a given release date. They would do the calculation based on the stories in the backlog, which represent business value. If the team's calculated velocity includes story points allocated to bug fixing or tasks that do not represent added business value then it is like comparing apples and oranges.
It is noticable that a lot of agile tools recognise this. For example, JIRA Agile only has the story point field on stories and not on other issue types.
As an example, consider a team that decides to allocate story points to bugs they fix in sprints. That team typically manages 20 points worth of stories in a sprint and around 5 points of bug fixing. They record their velocity as 25 story points per sprint. The Product Owner asks for a release planning session as they plan to do a release in a sprints time. They look at the backlog to work out roughly how much work they are likely to complete for the release. Can they assume they will complete around 25 points off the backlog? No they can't, because chances are they will also be fixing bugs as well. So it is likely they will only complete 20 points off the backlog before the release.
It would worry me if some members of the team thought it was necessary to reflect bugs in the velocity. That might indicate that they see the velocity as a measure of the performance of the team rather than purely as a means of estimating future sprint capacity.