SM's sensible action when impediment raised from Dev Team

There is something wrong here, if Dev team is not able to complete the work it is not an impediment, Dev team should negotiate it with PO, scrum master can just facilitate the meeting.

Cheers
Sanjay

If the Development Team finds it cannot complete its work, this might be due to an impediment which the Scrum Master can tackle.

Examples include external dependencies or the sudden absence of a critical resource.

If the problem is a matter of overcommitment, or the work in the Sprint Backlog is subsequently thought by the team to be unactionable within the Sprint, then they will need to liaise with the Product Owner as Sanjay describes.

Any impediment raised by the scrum team needs to be addressed by scrum master as this is one of the primary way in which the scrum master can improve team productivity. Usually impediments are raised during the daily scrum as part of issues / blocks reporting. I have seen cases (mostly if the teams are remote) where the issues will not be reported in daily scrum and SM will need to apply other techniques to see if things are blocked.
During the initial stages of project, all kinds of issues will be reported as issue / blocks. For e,g PO having second thoughts on a story requirement, or waiting on some other team member to complete , waiting on external inputs etc. Generally a discussion needs to be had to come to an understanding as to what constituents an impediments or blocks that needs to be addressed by SM

Hi Mouli,
this is a question from the PSM I assessment. The only right answer is: If the team is not able to fulfill the DoD, the SCRUM master should work with the team to find a DoD they can fulfill (short term), and support them to improve their skills and the DoD step by step (long term).
This problem is completely different to a team not being able to deliver everything that is in the Sprint Backlog. For that problem of course they will re-negotiate the Sprint Backlog with the Product Owner.
Best, Ludwig

Wouldn't it depend on if there's an outside impediment or not?

So if the Dev Team can't complete its work because they are waiting on something from an outside party (outside of the SCRUM Team), this would be an impediment and the SM should get involved to remove it.

But if the Dev Team "bit off more than they could chew" (perhaps they didn't realize testing a story would be so time-consuming), then they would re-negotiate with the PO.

Examples include external dependencies

@Ian, what can a Scrum Master do to genuinely help resolve external dependency impediments? In my experience, as it is an external dependency, the SM can usually (not always) do no more than provide an update on the status of the dependency.  

Because it's simply 'chasing', is this reasonable task for the SM to take on?  Would the SM be better suited to finding/coaching a solution to prevent the need for such dependencies or to help the team member identify such dependencies earlier, such as in refinement? 

What's the best approach to striking a balance between genuine impediment resolution and assisting with busy-work?

What a Scrum Master needs to do is to put transparency over the issue and its consequences. That may be the only thing he or she can do given a very constrained remit within an organization. Nevertheless, transparency is a critical part of establishing agile hygiene, and should be seen as important even when there is currently no organizational appetite for resolution.

Examples of transparency include agile health checks, end-of-Sprint summaries which are unsparing in their observations, deficits for release where a Definition of Done is inadequate, and assessments of technical debt. This is on top of blockers on information radiators which ought to be cultivated even if stakeholders take no notice.

My advice is that instead of reactively chasing the tail of each external impediment as it arises, the "chase" is to find a sponsor with:

a) the power to resolve the underlying systemic issue (e.g. insufficient team skills or authorizations)

b) who cares enough to effectively become an agile change agent

In short it may be seen in the context of a Scrum Master's agile coaching service to the organization, though it is not always appreciated. The pressure is always on to just muddle through and to succumb to organizational gravity.

Yep, got it.  Thanks :)

From the Scrum Guide, section on "The Sprint".   https://www.scrumguides.org/scrum-guide.html#events-sprint

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned

I view this as even if the team has taken on more than they can complete, something has been learned and negotiations should begin. 

Also from the Scrum Guide, section on "The Scrum Team".  https://www.scrumguides.org/scrum-guide.html#team

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. 

If a team discovers a problem that is blocking them (i.e. impediment) they should bring it up in the Daily Scrum.  If the Scrum Master can help remove the impediment, then that is what happens.  However I have seen multiple times that when one team member brings up an impediment, another member usually says "I can help with that" or the team discusses it and comes up with an action plan.  As the statement above says they should be able to complete the work without help from outside the team. I realize that is not always possible but it should be the goal.

The says the only mentions removing impediments when describing the Scrum Master.  But in fact, if the Scrum Master is helping the team to be self-managed self-sufficiency, they can remove their own impediments and they are going to be even more productive. Helping the team remove the impediment is often better than doing the work to remove it. 

So my answer to the original question is that the Scrum Master should bring the team and PO together to discuss the reasons that the work cannot be completed.  At the same time, the impediment should be discussed by all of the Scrum Team. An set of actions should be arrived at for both situations. 

Starting with the original issue in question,

unable to complete all the work that is committed and described in DoD

I think it needs further drilling-in to find out what the team is really saying. As @Sandeep noted, there needs to be a common/shared understanding of what constitutes an impediment. In general, an impediment is anything that obstructs the team from achieving the expected progress during a sprint. Therefore some of the first questions to ask the team are:

1. What exactly is the impediment?
2. What is impacted by the impediment?

I feel it is important to be precise for the SM and team to understand the nature of the 'impediment' because actions may be taken on the wrong things, which would be completely counter-productive. Beyond the first questions above, the 5 Whys technique can help here.

E.g., if an impediment is raised because the team over-committed, then it is not really an impediment (i.e., obstruction), and the corrective actions may be to be more realistic with the team's expected productivity and story estimation, or as @Sanjay noted, improve on the negotiation with the PO on the sprint backlog, depending on what the 5 Whys uncover as the root cause of the over-commitment. The corrective actions are again different if the impediment is due to reasons such as external dependencies, late identification of additional tasks, inadequately written stories, scope creep, etc.

Beyond the initial clarification of the impediment, I believe the SM does play a key role in executing the corrective actions, be it removing the impediment on the team's behalf, coaching/working with the team to remove it or avoid it in the future, or reaching out to a sponsor with the power to do so as @Ian suggested. Just bear in mind that ultimately it is better for the team to be self-sufficient as @Daniel pointed out.