We recently began working on Scrum with one of our products. Prior to that we worked with a Waterfall methodology.
We have created stories for the new feature and also included the bugs for the next release and we are estimating stories in story points. We are not sure how to deal with bugs. Do we need to estimate in story points or number of days for bugs?
The team finds that, for some of the bugs, most of the effort is taken up by analysis since the bug requires debugging and trouble shooting efforts rather than actual code implementation.
How do we estimate these specific cases, where the bulk of the effort is spent on analysis and some of that analysis may take days to weeks to complete.
Choose a consistent estimation approach that uses story points (don't rely on hours).
You have options:
Don't ever estimate the size of the defect in story points. Reasoning, a defect arises when a previous acceptance criteria from an existing (already estimated) story was not met. Estimating the defect in a way then double counts the part of the work required to deliver the story.
Outcome, iterations with many defects show a lower velocity. The team is forced to discuss why their velocity has dropped and why so many defects are occurring. Con...its harder for the team to commit to completing everything in the iteration if they haven't sized it formally.
Always story-point estimate the size of the defect. Reasoning, in an iteration we want to align the story/defect workload with what the team has capacity to complete.
Outcome, the team maintains a consistent velocity and can accurately commit to work within an iteration. Con...it isn't as obvious empirically that value added work is dropping as defect load increases.
Hour estimation and tasking are at your discretion in Scrum. Personally I advise against formally tracking tasks or hours in your scrum software as it creates additional overhead and can give an undesirable micro-management feel to some teams.
If you are doing Scrum make it as a policy that you are going to talk about the progress of bugs during the daily standup meeting. When you know what the root cause is you can start to handle the bug as a user story: you can give size or estimates because you know what you are dealing with.
If you hear no progress - let's say in 2 or 3 days - about the issue you should do something about it because a serious bug can risk your project. You can either suggest to have more people on the problem, you can cancel the sprint (discuss this possibility with your PO), or you can escalate the situation and ask for suggestions from the PO or other teams.