4

I have come to a team that is just starting to implement scrum. One reality that we are going to face is what to do when an emergency occurs.

In this case, we have a system that started failing while we were inside of our sprint. It's a critical system, so triageing the failure had to become the top priority.

Here's how I've done it in the past: (note, we were not using any sort of electronic scrum board or burndown, it was on paper and stickies):

  • Wrote the fire up on a sticky that was a different color than the planned items
  • Got an activity-point vote as soon as the team understood the problem well enough to vote it.
  • If necessary, removed an item from the sprint backlog
  • Updated the paper burn-down to reflect the change.
  • Noted unplanned work in an Excel spreadsheet that we used for tracking our velocity

At this shop, we are trying to use TFS 2012 and the Scrum 2 template (with the web-based scrum board and burn down). Is there some guidance on how to notate this using the template?

JMarsch
  • 173
  • 1
  • 4

2 Answers2

3

Scope of Answer

Others will hopefully address your Team Foundation Server template question. My answer is focused more on the issue of how you should handle the interruption from a process standpoint.

Abnormal or Early Termination

In this case, we have a system that started failing while we were inside of our sprint. It's a critical system, so triageing (sic) the failure had to become the top priority.

This is exactly the use case for an Early Termination of a sprint and a return to Sprint Planning. Unless you already had spare capacity in your sprint which could be allocated to your triage or break/fix process, it is likely that this interruption (and the task-switching that goes with it) has impacted your team's productivity for the sprint.

By all means, perform the business-critical work necessary to get your systems up and running again. However, immediately afterwards the entire Scrum team (including the Product Owner) should assess the sprint to see if your Sprint Goal has been compromised. If you can no longer meet the goal, or if assessing the impact to the sprint requires the team to re-estimate or refactor the Sprint Backlog, then you should have the Product Owner terminate your sprint and return to Sprint Planning.

Since you say that your team is new to Scrum, the team will be better off calling for Early Termination on principle. Re-planning is the safer (and framework-sanctioned) route for what you've experienced. Seat-of-your-pants adjustments to the Sprint Backlog and on-the-fly analysis of your Sprint Goal are adventuresome options sometimes undertaken by experienced Scrum teams with a high tolerance for schedule risk, but I certainly wouldn't recommend them as best practices to a newly-formed Scrum team.

Todd A. Jacobs
  • 46,657
  • 5
  • 51
  • 166
  • In TFS, you would just change the end date of the Sprint, and start a new one. – Andrew Clear Mar 12 '13 at 04:10
  • @CodeKnome I agree in principle, and we may have to terminate, but I think it would be better to avoid it if possible. We do build in time for distractions, and we may be able to absorb this. Here's why I'm hesitant to terminate:The shop has a history of quality problems and long tradition of fire management. One of the reasons that my position was created is help to help them to evolve away from this. To get scrum off the ground, we have to be able to tolerate some fires while we get our quality story fixed or I'm afraid that every sprint will end prematurely (hence the built-in capacity). – JMarsch Mar 12 '13 at 13:20
  • 1
    I am giving you the answer, because I think that evaluating the impact on the sprint and potentially terminating is the correct thing to do per the framework. – JMarsch Mar 12 '13 at 13:21
  • I prefer to only terminate if you are actually invalidating the sprint and stories that were chosen and need to replan. If it is a fire, customer issue, maintenance, ect. then I like to treat it as overhead that pushes down the teams possible velocity and ability to work on the planned stories. After a few sprints you will get an understanding of how much you can realistically do on the planned backlog VS. the in the moment business fires. Maybe the velocity is OK, maybe its not. Decide how you want to use scrum to visualize your environment. – Erin Beierwaltes Mar 13 '13 at 16:37
2

You essentially follow the same process in TFS

Wrote the fire up on a sticky that was a different color than the planned items

You can write up a new story (Product Backlog Item in TFS) in the backlog for this fire fighting work. It won't be in a different color - but, apply the top-most priority to it.

Got an activity-point vote as soon as the team understood the problem well enough to vote it.

In the same way, get the team to estimate the points.

If necessary, removed an item from the sprint backlog

In the same way add this story to the sprint and, if necessary, remove an item from the already scheduled work in the sprint.

Updated the paper burn-down to reflect the change.

The built-in burn-down report in TFS shows the task hours. If you want the burn-down in terms of story points, you have to create a custom report.

Noted unplanned work in an Excel spreadsheet that we used for tracking our velocity

The built-in velocity report will show completed points - except that there is not a way to factor the disruption to the sprint. If this is a big change, you can stop the sprint and start a new one with the revised priorities.

Ashok Ramachandran
  • 10,912
  • 1
  • 19
  • 49