What happened if a critical component cannot complete within a Sprint

A couple of things stand out in the situation that you describe. Why is a single individual responsible for tasks, or where is the team commitment to the Sprint Goal? Why does the team (or at least this one individual) not have the courage to be able to accurately state when work is at risk of not being completed and ask for appropriate help?

Those are questions to examine at the Sprint Retrospective, but doing so are critically important.

But we also have a here and now. As a Product Owner, you should engage the Scrum Master on the concerns. You can also start to work on reordering the backlog and managing stakeholder expectations. The best things that you can do, in a Product Owner role, is to make the current state of the Product Backlog visible and transparent and to be sure to maximize the value of the Development Team for the next Sprints.

Why was he “reporting” progress at all, given there was an emergent body of work that presented risk? Weren’t you collaborating as a Scrum Team during the Sprint, so that progress would be transparent, and you could inspect and adapt accordingly?

Thank you Thomas and Ian for the response. Both of you have raised valid points. 

However, I couldn't able to answer the questions as the example that I raised is not a real-life situation. There would be a number of suggested reasons arise to such situation, e.g. inexperience of the team, product owner or scrummaster etc. which I probably won't talk about it. 

But, in the event that thing do happen, what will be the best course of actions for the product owner or the team? Should the sprint be extended since this is a critical component? On the other hand, I understand that it is not advised to extend the sprint under normal scenarios.

Cheers!

On the other hand, I understand that it is not advised to extend the sprint under normal scenarios.

It is never advisable to extend the length of an active sprint at any point in time.   To do so is a direct violation of the sprint time box.   The only acceptable point in time to adjust the sprint length is at the conclusion of a sprint, before the next sprint begins.

To put it another way, would you move a bullseye target to improve the accuracy of an arrow you just shot?

But, in the event that thing do happen, what will be the best course of actions for the product owner or the team?

My answer to that question is that Thomas, Ian and Timothy have already answered it. This isn't an individual's issue. It is an issue for the entire Scrum Team if this situation comes to fruition and isn't made apparent until the end of the Sprint. There should be constant communication among the team, especially when something endangers the items needed to satisfy the Sprint Goal.  If this happens, it should be the first, and possibly the only, item that is discussed in the Retrospective for that Sprint.  And it should be a continuing discussion among the Scrum Team as you progress going forward so that it is avoided in the future. 

Hi Daniel and Timothy, 

Thank you for your responses. I totally agreed with both of you. The best course of action is to let the scrum team to decide and learn to avoid such issue occurs in the future.

Cheers!!