4

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?

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?

  • Some weeks it does not happen, other weeks especially when have released a new version of the product it happens. – bobo2000 Apr 27 '16 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 '16 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 '16 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 '16 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 '16 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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