5

In the middle of a sprint right now, the following problems have arose:

  • Urgent bug has cropped up that needs resolving

  • Stakeholder urgently needs a requirement integrated which is preventing a deliverable from going live. This was missed out during planning because they did not realise at the time they needed it.

In terms of story points both tasks are (0.5 points) after speaking to my dev team during a daily stand up. To fit this into the sprint I replaced an equivalent story in the sprint that is (1 points) with both of the 0.5.

0.5 + 0.5 = 1

If these tasks were not urgent, I would have put them in the backlog and waited for the next sprint cycle to begin.

Is this the correct way to handle the situation?

Improve this question

1 Answer 1

Reset to default
7

As long as Sprint Goal is kept the Sprint Backlog can be changed as needed.

In the Scrum Guide is written:

During the Sprint:

  • No changes are made that would endanger the Sprint Goal;
  • Quality goals do not decrease; and,
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

What else can you do?

  • Cancel the sprint and start all over? It is very traumatic for the team at it seems Sprint Goal is valid.

  • Continue on the agreed scope? What would be the consequence?

You mentioned you discussed this with the Development team. As the Sprint Backlog is owned by the Development Team they need to agree on the scope change. If they did, that is OK. It is always better to explain to the Dev team why would you like to modify the Sprint Backlog.

Especially, if they did not yet start to work on the item that should be put out the impact of they work should not be high.

On the other hand, one has to be careful. Are you sure the tasks are urgent? Does this happen often (if it does, something is probably wrong - length of sprint, understanding how your team works by stakeholders, poor sprint planning discussion,...) ?

I would also suggest to discuss this in the sprint retrospection. Will the team think that it significantly impacted their work?

Improve this answer
6
  • Some weeks it does not happen, other weeks especially when have released a new version of the product it happens.
    – bobo2000
    Apr 27, 2016 at 13:08
  • One has to keep in mind that each time it happens the team can lose focus and decrease productivity. I do not know how often you release your product but if you have several sprints between releases and you find during the first sprints about something new, put it to the next sprint. Do not change current one. But You (I mean whole scrum team) know about the situation the most. It is up You to judge.
    – MasterPJ
    Apr 27, 2016 at 13:36
  • I release increments weekly. I try my hardest to stick to this rule, but sometimes I am put into situations where it is an urgent request
    – bobo2000
    Apr 27, 2016 at 14:31
  • If your team loves the product they develop, and there is rationale behind the urgency, why is that an issue?
    – Bartek Kobyłecki
    Apr 27, 2016 at 15:19
  • 1
    @bobo2000 It is not a good practice to change sprint backlog mid-sprint if it happens regularly. However, as you have mentioned Some weeks it does not happen, other weeks especially when have released a new version of the product it happens, this seems fine to me. Don't let the process hold you back in delivering valuable working software. If a new version / release needs some minor tweaks as hotfixes then do that.
    – Aziz Shaikh
    Apr 28, 2016 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.