Handling blocked tickets

[DarkKnightess]

We had a ticket in our previous sprint which we couldn't close (deploy to release) as business asked us to put it on HOLD, due to some last min changes that happened and moving that piece would have given a wrong picture to our end users.

We spilled over the ticket and took the ticket in our current sprint to continue on the required changes, but again today we got to know that business is still not clear and hence our PO has asked us to put it in BLOCKED status as we might come back to it only in the future once the changed requirements are clear.

What would be the best way to tackle the ticket, below are the two options I am thinking of:

1. Keep the ticket in blocked status in the sprint and when the sprint is over, just move this to the backlog.

2. Remove this from the sprint right away and put it in the backlog.

[Nic Brough -Adaptavist- · Accepted solution]

If the business doesn't want this doing and you don't know when they might change their mind, then it's totally unfair to ask you to try to plan for it.  And you certainly shouldn't plan for it either.

It should go back into the backlog, with a much lower rank than stuff you can plan for, and left there until they can make up their mind.

[DarkKnightess]

Thanks for the reply Nic.

Do you think its better to keep it in the sprint backlog till this sprint gets over (in Blocked status, ofcourse) and then move it back to the Product backlog when the sprint closes?

Or do you suggest to REMOVE it from the current Sprint while we are in the middle of the sprint (will change the scope) 

[Nic Brough -Adaptavist-]

For the description you've given us, I would move it out of the current sprint and back into the backlog.  It will change the scope, but you have a perfectly good explanation for why it's a change.

[DarkKnightess]

Thanks Nic. Appreciate your quick reply.