Failing and external dependencies

Why not limit work in progress to (say) one item at a time? Then if there are unforeseen problems they can be be identified and dealt with quickly, and without excessive undone work building up.

To me, failing isn't the issue, but repeated failing around the same tool or external dependency is.

Are these blockers/impediments discussed in the Sprint Retrospective, and is there a strategy to avoid such occurrences going forward?   How is the team attempting to mitigate the repeated occurrence of such incidents?

As an example, one of my teams had a similar issue where they were at the finish line, but environmental issues causing their Bamboo build to fail prevented them from delivering their work to production.

Now, the team has part of their routine to execute a Bamboo build in all environments at the start of a sprint for whatever applications they are touching.   This way, if there are any issues, they are identified early on, and greatly improve the likelihood of both timely resolution and delivery of business value at the end of the sprint.

If this happens consistantly, maybe reserve some time in your planning for these kind of activities. Maybe the time reserved will not be spent on external blocking issues, which can be used for pulling extra work from the PB.

To me, failing isn't the issue, but repeated failing around the same tool or external dependency is.

I think Timothy's point is key here.

A K, why not coach the team to have PBIs ready for sprint planning. If external dependencies are not resolved/fixed, then the PBIs may not be ready, hence can't be considered at sprint planning; once the dependencies are fixed, your future sprint planning may take into account those PBIs.

The PO would surely realize the danger of not delivering constant value, on a regular basis, hence their efforts towards securing a clear path for the DT.

Conversely, if such dependencies cannot be addressed before sprint planning (aka parallel work is required), why not look into ways to fix the root cause? Is your team a feature team? Are those "external blockings" external as in third-party or other internal teams/streams? Is scaling required if work's done in parallel? Why don't you inspect and adapt on a daily basis (daily scrum)? Etc etc

All the above and ...

Refinement is the place I coach my teams to uncover these as much as possible. If this is a common occurrence then it should be possible to recognize it.  Every Review this kind of thing should be discussed to make transparent the problems being encountered.  If no immediate solution is evident, Retro is a good place to do more in depth inspection.  Have the teams determine a method that could prevent these as much as possible.  I have teams that identify these type of operational issues and request any dependent team/service to fix the issue before they will consider bringing the PBI into their sprint. 

I want to point that I said "as much as possible" because there will be times that something happens that was not/could not be foreseen.  Just do what you can at the time, inspect it and adapt using the Daily Scrum as a vehicle for the identification. Then repeat everything I said in my first paragraph as an added measure of knowledge. 

One more thing before I close.

These are fully out of our scope. Like some tools fails to work properly and by the time they are sorted out its already too late.

Could it be that the team is including too much work in their forecast since it sounds like they aren't leaving bandwidth to deal with unexpected findings?  Maybe that should be a discussion among the team.  Remember the outcome of a Sprint is a potentially releasable increment.  If the Development Team is forecasting too much work, it will impact their ability to consistently deliver the increment.