How should we manage/point ad-hoc support queries that come in after the sprint has started?

Question

I've come across a slight dilemma which, as far as I could see, has not been answered in Scrum blog posts on the interwebs, nor in this StackExchange.

We started our sprint and a day later one of our devs, who is currently pairing, is now being required to investigate an urgent production issue. This is business critical and the dev is being pulled in to support this work. Now we would like to track effort spent on this support issue but there is no real timeline on when our dev will complete the work involved.

We have created a story for this support work and pulled it into the sprint. I guess... Question 1 and 2:

• Was this the correct thing to do?
  • It feels like it was because due to the effort currently being spent on supporting this Prod issue.
• Should we have pulled it into the sprint?
  • Feels like it was right to do as it is being worked on in the current sprint. And also from a visibility point of view, we are displaying the work that the dev is currently assigned to.

We also didn't put an estimate on the story. This was due to the inability to estimate such an unknown. As something like this hasn't happened before so no historical data to look back on and it not being something we can simply time-box, we cannot estimate it as a time-boxed event either. So Question 3:

• Should we have estimated the story before work began on it?
  • If so, how would you have had the team estimate such a piece of work?

Would love to hear people's views on the above questions and what my reasoning was to the way we handled the questions.

I have also queried another SM within my business and their stance was to retrospectively put an estimate on the story to reflect that amount of effort spent by the dev on the support provided for this Prod issue was once they're done with it. Their reason being due to the uncertainty of the work involved, the uncertainty of the amount of effort that will roughly be spent on this and to then in the future be able to track effort spent on it (to also help with future capacity calculations). I know the reasoning as to why you never re-estimate a story once complete but due to not being able to estimate to begin with (assuming the previous questions don't drum up an appropriate answer) Question 4:

• Is it acceptable in this scenario to retrospectively place points on the story once work involved is complete?

A few other things to note also is:

• When planning our sprints we generally plan to 65% of our capacity per sprint, Allowing for things like support queries or defects to come to us before sprint planning commences (but note in this case truly unable to put a reasonable estimate on the size of work/effort involved this and this came in after the sprint started and became highest priority item).
  • Also if this support carries on into the next sprint would we create another story?
    • In that case would the expectation be to point and close off current story and create a new one and try to make a reasonable estimate on remaining work, if possible? If not leave it with no estimate again and maybe, if people suggest, to retrospectively estimate it?
• One other solution may be to I suppose abandon the sprint, exclude the dev from the team and adjust capacity to exclude that team member whilst they work on supporting this Prod issue.
  • Problem is the way our Jira is managed we cannot abandon the sprint for one team as due to the setup it would abandon the sprint for all teams (So not a viable solution unfortunately)

If anymore detailed is required I'd be happy to provide it. But yeah, I am slightly stumped at this one as naturally we wouldn't change story points once the story is completed and we wouldn't pull in work unless team is able to complete it in the sprint (and rest of dev team doesn't require assistance, etc.). So I am not entirely sure what to do. Whether to point the story after work is completed, to have pulled it into the sprint or not, etc. I look forward to hearing what people have to say on this.

Answer 1

Urgent issues happen. Any Scrum Team that is supporting an operational system must consider how to handle reports of critical defects, system outages, and other types of unplanned work that go into making sure the system remains online and meeting the needs of stakeholders.

If the work is important and urgent, you need to pull it into the Sprint. You cannot wait days, or perhaps weeks, for the work to go through a regular Sprint Planning session before starting it. Although it's good to triage and understand the issue and why it is considered urgent, it's a minimal expectation to do this triage and at least identify if there are suitable workarounds that can decrease the urgency of the work quickly. From a visibility perspective, you are going to want to make sure that your Sprint Backlog reflects this work so your key stakeholders know what the team is working on and any impacts to the previously planned work.

There's no need to play games with work in your work tracker based on when the work comes in. Open the issue or ticket to represent the urgent work, open work to track any dependencies or discovered items, and close the work when it's done. It's OK for work to transcend Sprints and releases and you don't need to add administrative burden with opening and closing items in your tracking tools.

Whether or not you estimate is up to the team.

Personally, I recommend that teams generally avoid estimation. It's not a value-adding activity and comes with a lot of issues. Especially in the case of urgent work, estimating won't change the urgency of the work. Assuming you have enough detail to estimate, estimating will only delay the completion of the work and, at best, will give you a very rough idea of what work may be displaced by it. My preference is to focus on understanding what is being asked and right-sizing work. In the case of urgent issues, identifying the minimum work necessary to reduce the urgency and have follow-on activities go through routine prioritization and planning activities.

I'm also opposed to retrospective estimation. By the time the work is done, you have actual measurements around lead time and cycle time. These actual measurements are far more powerful than any estimate and can be useful for any kind of work to understand how much the team can do in a unit of time.

Keeping track of urgent requests that come in the middle of a Sprint, how much time you are spending on those requests, and if there are external factors that may trigger changes in the urgency or frequency of urgent requests can help you plan. Planning to somewhere between 65% and 80% of the team's capacity against a planned Sprint Goal is good and should leave enough buffer for not only urgent requests but also unplanned reductions in capacity. Having hard data on when requests come in, how much of your capacity you spend on those requests, and working to reduce the number of urgent requests can help increase the amount of time dedicated to planned work.

Cancelling a Sprint is the most extreme case. The Scrum Guide leaves it as a last resort for when your Sprint Goal becomes obsolete. If you are leaving adequate capacity in your planning to handle unplanned work, you should never have to cancel a Sprint because of urgent and unplanned work coming into the team.

Answer 2

TL;DR

It might be useful to estimate a story spike like triaging an unexpected bug, but it's not useful or valid to estimate work unrelated to the Sprint Goal or outside of the Sprint Plan other than to estimate whether the new work will fit within the Sprint without endangering the Sprint Goal.

In all other cases, either:

1. do the urgent work with the expectation that the Sprint Goal may not be met; or
2. swap out other work after renegotiating scope with the Product Owner.

A deeper analysis and some key recommendations follow.

Analysis and Recommendations

Now we would like to track effort spent on this support issue but there is no real timeline on when our dev will complete the work involved.

Why? Your question can't really be canonically answered without an understanding of why you (or the organization) thinks there is value in estimating unplanned work.

[R]etrospectively put an estimate on the story to reflect that amount of effort spent by the dev on the support provided for this Prod issue was once they're done with it.

This is an anti-pattern because:

1. It is simply an attempt to show effort expended (which is not a Scrum metric) instead of Scrum Goals, Product Goals, or completed Increments of the Sprint Plan.
2. Story points, velocity, and related metrics are useful for estimation during Sprint Planning, and have absolutely no place in retconning your Sprint Backlog.

Story Points and Velocity

The value of story point estimation is fundamentally capacity planning for an iteration. Outside of capacity planning, estimating story points has little to no value.

If you don't meet your Sprint Goal, then your story point estimates and velocity metrics are measuring the wrong things. Therefore, once a Sprint starts, the correct process would be:

1. Respect your work-in-process limits; that may mean stopping other work to focus on the "urgent" issue.
2. A half-day or full day of triage as a story spike to estimate the impact of the unplanned work belongs on your Sprint Backlog, but you can't really estimate level of effort so don't waste time doing that.
3. If your story spike results in a level-of-effort required to "do the thing" (whatever it is) then the Developers can use that estimate to determine what can be ejected from the Sprint Backlog to make room, or the Sprint Goal renegotiated with the Product Owner if it puts the current Sprint Goal in jeopardy.
4. If the "urgent" work is more important than the Sprint Goal, either plan on not completing the Sprint Goal (in which case the team may as well swarm over the "urgent" item, bug, or whatever it is) or address the risk to the Sprint Goal with the Product Owner.
5. Drag on velocity or a reduction in story points completed due to unplanned work should not be retroactively planned; that destroys the transparency of the process and skews the velocity and capacity planning metrics to the point where they are no longer useful.

In short, accept that unplanned work will disrupt the plan. Do not sweep that under the rug. Disruptions should be visible and transparent, otherwise you are not meeting the Scrum Values or the framework's theoretical underpinnings as defined in Scrum Theory.

Increase Visibility and Transparency

Ad-hoc work creates drag on productivity. Period. That should be made visible to the Scrum Team and to project stakeholders, and the impact on the process and the budget should be transparent to anyone who cares to inspect the process.

During the inspect-and-adapt processes within Scrum such as the Sprint Review and the Sprint Retrospective, routine drag on the team's productivity should be carefully evaluated to determine if:

1. It's a problem with product quality, which should be reflected in an improved Definition of Done and a more test-driven mindset.
2. It's a process problem where issues that could wait a couple of weeks to be prioritized and included within the routine cadence of Scrum iterations are being injected without considering the impacts on cost, schedule, or scope.

The latter tends to be more common, and is typically a symptom of one or more of the following:

1. A lack of trust between stakeholders and the Scrum Team regarding the reliability of the team's cadence for delivering Sprint Goals and Increments.
2. A lack of training and information, both within the team and with stakeholders, about the built-in inflection points that would not disrupt the team's cadence but still provide predictability about when issues could be addressed.
3. A framework implementation dysfunction where the framework's theory, values, principles, and events are given lip service but not actually being followed.

While there are always one-off edge cases that arise from time to time, a routine pattern of not following the implementation patterns that make Scrum successful will ultimately lead to its failure. Business needs take priority, but failing to build a sustainable process around incorporating changes in business needs is what typically leads to a 68% failure rate in projects.

Scrum doesn't make project management or business problems go away. All it does it make them more visible so that the Scrum Team and the project's stakeholders can collaborate on solutions. That's what you should do both in the immediate case and in the general case; the rest is just a set of implementation details about how to do that within the Scrum framework.