Regarding any unplanned work (defects, bugs, etc) do we really need to estimate?

The Scrum Guide says:

"At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress."

It depends.

If it's unplanned because it was introduced and discovered as part of new work, I tend not to estimate that. The work that was initially planned was estimated, and the discovered defects represent undone work. If the defects lead to planned work not getting to done, especially if the Sprint Goal isn't met, that can be something the team talks about at the Sprint Retrospective.

If the work is unplanned because it becomes urgent after Sprint Planning, then it should be estimated so the team can evaluate what work is likely to be impacted. If the team has the capacity to do so much work and they plan to do that much work in the Sprint, then you can't add more work to the team and expect them to get it all done. Depending on the size and complexity of the unplanned work, the team can assess the impact.

There are some caveats. For some urgent issues, there may need to be more extensive research. Perhaps there is insufficient information to estimate and the team is performing an immediate refinement and then doing the work and stopping to estimate would only slow the team down in fixing the problem. There is also a time factor, where you don't want to spend too much time estimating that could be done using value-adding work.

Ultimately, it's up to the team to consider based on the urgency of the work and available time. I don't think that there's a single right answer that applies to all cases.

"At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress."

@Ian Mitchell, I understand this, however, if there is an urgent item, does this need to go through the process of estimation in the face of that urgency? let's say its a critical incident in Prod, usually has an SLA of 1-3 hours, do we still need to estimate even if an SLA is defined?. In my experience, such work usually halts the other WIP, the other WIP can still be summed though. The only thing I'd consider is how this may impact the Sprint Goal and the current WIP and to make decisions on adjusting scope if needed.

Maybe, there is a better example that I am missing that communicates your point better. Could you help me with that?

If the team are indeed able to adjust scope so the Sprint Goal is met, then the work remaining is effectively summed. It's just that the team have not gone through their usual process of estimation, and it may have been comparatively qualitative. The team might nevertheless have a shared view of work remaining, and they could still be able to manage their progress.

Remember that Scrum is non-prescriptive about how estimation is done by a team. Examples include:

• Story pointing
• T-Shirt sizing
• Same-sizing and calculating throughput (cf. #noestimates)
• Experience: does the work remaining look and feel achievable
• Wetting the finger, putting it in the air, and rubbing the stomach

I think a greater concern, in the situation you describe, is whether or not the handling of the incident causes WIP limits to be broken, since this would affect service level calculations.

I think a greater concern, in the situation you describe, is whether or not the handling of the incident causes WIP limits to be broken, since this would affect service level calculations.

@Ian Mitchell, We are using an expedited lane to handle urgent and unplanned prod support, or similar issues. I believe this would not impact the limits of the standard WIP. However, at the same time I am emphasizing that we assess if any work in the expedited lane would threaten the Sprint Goal and if we should consider adjusting scope to meet the Sprint Goal.

What are your thoughts on such an approach?

If your Sprint Goal is to deliver a feature of some kind, then WIP ought to be managed to achieve that outcome. An expedite lane will cause WIP limits to be broken, but as long as the impact is understood the team could permit this as a policy.

If your Sprint Goal is to achieve a given Service Level Expectation, then difficulties may be encountered by having an expedite lane, because WIP limits will vary. The ability to make forecasts regarding cycle time and throughput would then become more complicated.

@Ian Mitchell, Some interesting comments. I agree with the cycle time and throughput not becoming predictable but I was of the impression that the expedited lane does not count into the regular WIP. I need to explore this topic a bit more.

WIP means work in progress.  If that is expedited, normal or when-you-get-a-chance, if someone is working on it it is in progress.  

My opinion is that as long as you are having discussions on whether the expedite will impact your ability to achieve your Sprint Goal, you are doing the first thing right. It should be discussed every day in the Daily Scrum to ensure that the work being done on it is transparent to the entire Scrum Team and any impacts to the original Sprint Backlog and Sprint Goal are being considered.  It is ultimately up to your team to decide if this is working or not.  You do not mention that they have raised it as an issue so I am going to assume it is working.  This same method has served many of my past and present teams well.  

Expediting (whether done with an explicit lane or not) can be the best option for getting an individual item done quicker, but like any other variance of WIP limits, it makes your workflow much less predictable overall. Daniel Vacanti explains it brilliantly in his talk How an expedite request sunk the Titanic.

But the decision to estimate is separate to the decision to expedite.

An item may or may not be estimated prior to (or even after) expediting.

A high priority item may still wait until there is space on the board, before it is picked up.