Managing Risks and External Dependencies in Scrum

I cant suggest anything, and may be others too, because to understand the situation it os necessary to visualize and describe in regular human casual terms, not just in a framework of scrum guide...

Like for example " we are a Scrum team working for a website in a gambling industry in Vegas. To get user stories we need to rely on feedback from casino employees. But they getting drunk every day  so we cant get product blog refinement because of this dependency"

It is not a joke by the way.

With a scrum teams I work, I always bring any issue to everyday, simplified basics, and also insisting on simplification of language for any artifacts or documents, including backlogs or DoD. Taking in the account maintaining the value and quality of course. 

When you have dependencies on external teams, why are you selecting work that has those dependencies before they have been satisfied? Why can't you keep those Product Backlog Items on the Product Backlog until the dependencies have been completed - or at least sufficiently likely to be completed - such that the team's Product Backlog Item will be able to progress to a Done state?

It could also be worth looking at the external team. Are they within your organization or another organization? What frameworks or methodologies are they using to deliver to your team? Are there opportunities to work together on aligning delivery expectations and delivery cadences?

What Thomas said. 

Also, regarding…

Specifically, we would like to explore the idea of assigning a partial business value to a Sprint Goal affected by an unmitigated risk, so that the summary business value reflects the actual value delivered by the team.

While this might make the team feel better, it doesn’t provide your customers/stakeholders with any value.

Your business value would still be zero if the outcome associated to the Sprint Goal is not realized and delivered. That doesn’t mean the team didn’t do anything or that there wasn’t value in what they started, just that business value hasn’t been gained yet.

I would focus on what Thomas shared.

Our Scrum team faces challenges with risks that cannot be mitigated within the Sprint due to dependencies on external teams. As a result, when the risk happens and prevents us from achieving a Sprint Goal, our business value becomes zero for the goal.

Scrum is very good at exposing issues such as this very quickly. It hasn't created a problem, it has revealed an underlying truth.

we wonder if there is a way to account for risks that cannot be fully addressed within the Sprint. 

This has already been accounted for. Business value is zero. That's it. 

Be very careful not to seek some alternative means of "accounting" which covers the issue up. Your team has systemic dependencies which need resolving. They can't craft a Done increment under their own steam. That structural impediment has been beautifully exposed. Now, what is the organization going to do about it?

Thanks everyone for your answers

@Thomas 

When you have dependencies on external teams, why are you selecting work that has those dependencies before they have been satisfied?

Why can't you keep those Product Backlog Items on the Product Backlog until the dependencies have been completed - or at least sufficiently likely to be completed - such that the team's Product Backlog Item will be able to progress to a Done state?

Setting a clear goal helps the team understand what's most important and prioritize their work accordingly. This is precisely why we create goals.

During our retrospective, my team and I discussed the issue and we decided to adopt a new approach. Specifically, we agreed to keep any product backlog items with dependencies on external teams on the backlog until those dependencies have been completed or become sufficiently likely to be completed as you suggested.

@Ian, @Thomas 

It's true that our company has many teams, each using their own methodologies, which can make it challenging to align delivery expectations and cadences with external teams. As you pointed out, this may be a structural issue that we need to address.

what would be the case, backend team and frontend team are delivery one feature. however frontend team can not commit work. what if backend start coding and park the code ready for e2e testing then restart it until frontend is done? How to solve this kind issue? 

we know perfect scenario is both team are working parallel but in reality this can not happen. or can not even happen back by back.. 

Why do you have the front end and back end separated by teams?  Why not create your teams in a way that will allow a complete increment creation?  Create 2 teams that have front, back and quality assurance individuals on each team.  Split the work so that they can both work on improvements to the product without interfering with each other.