If the team is using Kanban, point estimating makes sense. That way the product owner can identify the risk of not doing the defect until later, as opposed to getting a new feature out. Many defects found really are more annoying and not critical defects. So a savvy product owner can identify which issues can harm the product without being fixed, as opposed to when a new feature is needed.
For Kanban, once the priority of the defect has been identified, then that token or story is placed on the appropriate place for that board. In both the Scrum and Kanban scenarios it is important to differentiate defects from stories. The reason to do this is to track defects, to make sure your quality process is on track.
For instance, see Example 1:
Example 1 (Sample burndown chart tracking defects)
Looking at this chart, our burndown shows that the team is working well through their commitments, and buring down well. However, the defects showing at the bottom show a disturbing tendency to go up more as we get through the project. Maybe this is expected from the team, but it would be great topic for a retrospective. Tracking how the team is doing with their defect rate has to help drive improvement.
Production Stopped Defects
The exception to the above is any defect that is affecting production. In this case the team needs to have rules on how to handle this before it happens. Make sure your team is prepared to handle these inevitability.
Certainly, if a critical production defect is found, the entire team can swarm on this defect to get the fix done, and pushed out to production. The advantages to this include a quick turnaround time. Also, the developers who originally worked on this piece of code would be involved. Although assuming the team uses Pair Programming, this would not be an issue. Disadvantages include the possibility of a Scrum team blowing their commitment to the sprint. For a Kanban team, this might cause them to blow their SLA to the customer.
These are the risks and advantages to using a swarm strategy. Another consideration here is how many critical defects on average does the team produce within a given time period. One would hope that this would be a rare exception, but sometimes that is not the case. Consider this aspect before deciding on a swarming strategy, and back it up with hard data.
Another way to handle these issues would be to designate a team member for a short length of time as your on call person. It has been called the batman position, the position no one wants and more. The idea is that this member of the team would not be counted on to contribute significantly to new project work for that period of time. They would have to triage the production issues to determine if they are critical and need to be fixed, or could they be put in the backlog.
It would also make sense for this position, during slack time, either works on prioritized work, maybe helping with testing, or make this learning time. Allow this person to investigate a new technology the team wants to use. Besides helping the team, this makes this position a little more attractive to team members. Usually this task is not one team members look forward to performing.
This method helps keep your new production work more predictable, and allows the team to focus on completing the work committed to.
Handling Defects in an Agile way
These strategies for attacking defects are not necessarily agile in nature. However they do work well in agile teams. The real trick is to make sure that the team decides on which method to use, this should not be decreed from management. Management can certainly demand that the team documents to them how they handle defects though. That seems reasonable.
Using some preplanned method for handling defects helps teams with a smooth delivery, and keeps them out of a reactionary mode. Make sure that your team has a plan!