Velocity affected when issues are re-assigned to another scrum team

Question

Our team commits to a certain story points per sprint - say 25 SP.

There could be 1 or 2 tickets which needs to be verified by somebody else not part of the scrum team. We have no control on this. Verification is not part of the 25 SP.

It ultimately affects the Velocity since the ticket remains in "Verifying" status and not closed when sprint ends. The responsible person would action on the ticket on his own time - according to their teams' priority.

There are two ways we handle this (but not effective)

* Remove the ticket before the sprint ends. 
* Let the ticket stay as "Verifying" status when sprint ends but dont carry it forward to next sprint.

Both cases we lose velocity.

Any suggestions how we can handle such scenarios?

Kiiko Orara · Answer

Thanks for the reply.

Ideally the next assignee would work on the ticket for the next sprint and recover the lost velocity immediately. This is not always the case for us.

And sometimes, the ticket itself needs to move from our board to their own board.

I feel we are missing a correct workflow here.

Sanjog Sigdel · Answer

@Kiiko Orara The case is similar in my organization. For the tickets which needs verification from other team we do the following:-

1. Develop it before mid-sprint such that the other member can prioritize it within a week. This will help most of the time and tickets get completed.

2. We keep such tickets assigned for Verification and move it to the next sprint if ticket is not completed. However the priority is set to critical for next sprint for the QA to pick it as first priority. It should be done in next sprint.

In terms of velocity that ticket say 5 points will reduce the sprint commitment. But it increases 5 points in next sprint as my team members have nothing to do on it.

In an average the historical velocity always gets similar to our expectation.