I use story points and the planning poker estimation game to estimate the relative size of user stories in my product backlog.
Todd Mercer recently asked if Scrum teams should estimate spikes, chores and bugs too.
Chores and bugs don't directly deliver value to our Dynamics 365 users. Bugs are defects in production that need to be resolved; chores are items that the Scrum team need to perform to improve their productivity. Spikes represent research work to evaluate options and reduce risks and are indirectly valuable to the organisation.
Todd's team does not estimate the effort of bugs, chores and spikes. His Scrum team only estimates the effort of user stories that deliver value to the Product Owner and users directly. His team's velocity represents a measure of the value delivered every sprint.
This is a good approach, and it's used by many teams including some of my Scrum teams.
By modifying this approach slightly teams can still track their velocity accurately but also improve capacity management. The modified approach is to estimate stories, spikes, bugs, and chores and use these estimates in capacity planning to determine how much work you can do in a sprint but exclude the estimates for bugs and chores from velocity tracking.
I include spikes when calculating velocity because they are often valuable work that provides clarity and reduces risk.
Critical and non-critical bugs
Critical bugs, by definition, can't wait until the next sprint. They arise mid-sprint, after sprint planning when our sprint backlog has already been estimated and committed.
We can either estimate the effort to resolve the critical bug, and remove another similar sized item from the backlog, or leave a buffer (5 to 10% of our capacity) to work on critical bugs during the sprint.
I prefer to leave a buffer. If a critical bug arises we can work on it immediately. If there aren't any critical bugs during the sprint, we can use the time to work on non-critical bugs or another item according to the product owner's priorities.