What does skilled inspector means

In Scrum there is no specific 'skilled inspector' role.  The Development Team is cross functional, and has all of the skills needed to produce the Increment and meet their Definition of Done.  If testing is needed, many people on the Development team may do it - but there is no specific testing role.  The Development team may choose to use tools as well, such as CI/CD and automation to inspect the Increment every time code is checked in, which is a good engineering practice.  They may not be at that point and may need to inspect the Increment by doing manual testing. 

Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

My understanding of that is each inspection opportunity should be held by and for the people targeted by each inspection event.

For example, in a daily Scrum the development team collaboratively inspects the last 24 hours. The skilled inspectors for this event is the development team. This inspection is most beneficial when diligently performed by the development team than by the Scrum master or the Product owner or someone else.

Another example is for the Retrospective. It will be most beneficial when diligently performed by the Scrum team than by any external stakeholder who did not live the sprint as a Scrum team member.

Please correct me if my understanding does not make sense.

Coming from a background in Lean and organizations based on the Toyota Production System, I think useful concepts would be just-in-time and jidoka. I think understanding some of the background with what I think the intention of this is will help to understand what is meant.

You want to do everything just-in-time. In order to reduce flow times, you want a piece of work to go through the entire process without stopping and waiting in the middle. This includes performing tests and inspections on the pieces of work during the process used to construct the work item. When your tests and inspections indicate a problem, you want to be able to immediately detect the problem, stop the process, correct it, and ensure that it doesn't happen again.

As a software engineer, the best example that I can come up with is code. Scrum helps to enable just-in-time work. Some level of effort is expended to organize and define the work (Backlog Refinement). However, once work is brought into a Sprint, it proceeds to a Done state relatively quickly. Along the way, you test and inspect. During Backlog Refinement, you'll make sure that there is enough information and the work is appropriately sized to continuously move through the development process. You don't accept work that isn't ready into a Sprint. Scrum teams are more successful when writing automated tests and employing Continuous Integration techniques to frequently run automated tests - this is another form of inspection. Static analysis and code reviews are also used to identify problems and concerns, including preventing work from being merged into a mainline or raising failing builds if code doesn't meet defined standards.

Now, consider all of the work products in Scrum - Product Backlog Items, Product Backlog, Sprint Backlog, your technical work products (in a software project, your code, tests, and documentation; other products have different technical work products). You can apply these concepts of just-in-time and jidoka to this work and other work that you do.

The "skilled inspector" that you use varies depending on the work product. In some cases, "skilled inspection" can be done by an automated process. In other cases, you need human eyes on the work. If the work being produced is code, a skilled inspector is anyone with knowledge of the languages and frameworks being used as well as the organizational standards being applied to the work. In the case of the overall product, the skilled inspector is someone with a good understanding of who the users are and the ways in which they will be using the product. In any case, it's someone who can look at the work that has been done and assess it with a knowledgable, critical eye and be able to raise flags and concerns about the state of the work.

The various Scrum events require certain participants, so they can inspect and adapt the work being done and the way work is carried out.

Each of the participants for an event described in the Scrum Guide ought therefore to be a skilled inspector.

If participants of scrum events are supposed to be the inspectors so I personally think these words needs be changed as these are not simple enough to be understood, "Inspections are more beneficial when performed by skilled inspectors at the point of work". As, as "skilled inspectors" is something not easy to understand for everyone.

Scrum is based on empirical process control theory.

The whole of the scrum events is based on enhancing the Inspection, transparency, and adaptation.

• Artifacts
  • Project Vision Statement
  • Prioritized Product Backlog
  • Release Planning Schedule
• Meetings
  • Sprint Review Meetings
  • Daily Standup Meetings
• Information Radiators
  • Burndown Chart
  • Velocity Chart
  • Scrum board

Scrum events/participants (only mandatory ) and Deligent inspectors 

Sprint planning 

• Artifacts

1. Ordered, prioritized, estimated product backlog 
2. Definition of done  (DOD)
3. Acceptance criteria (AC)

In here inspection is continuous and will be based on the area of interest 

Scrum master (SM) will inspect and adapt anything and everything related to process improvement.

ex: SM should inspect the prioritization techniques adopted by the PO.

     SM should inspect the estimation techniques adopted by the development team.

    ~ exhaustive list based on the situation of the project.

    PO and Development team should inspect and adapt Product backlog, DOD and AC based on the quality of the done increment and feedback from internal and external stakeholders.

Daily Scrum 

Self-organizing and the cross-functional team should inspect their progress towards achieving the sprint objective.

SM should inspect the team is following all guidelines etc

SM and PO should inspect the Burndown chart on daily basis and see if their intervention is required in daily stand up meetings etc

~ exhaustive list based on the scenario and situation of the project/ US

Sprint Review 

Of greater importance is customer/client/ SME  feedback and their inspection of the product during the presentation of done increment session

Sprint retrospective 

Inspect how the last sprint went with regards to relationships process and tools.

So on and on ....

I agree with Azhar. The term 'skilled inspector' gives a notion that there is a inspection team or role involved in scrum to a very first time reader of the scrum guide. I did not know until late in the Scrum guide where I found the inspection is done in the Sprint review. 

I feel since this in values section of the Scrum guide, hence they introduced this term there only.  

Can someone who is not part of the scrum team also be an inspector? 

Like a project manager or someone from management in the organization.

Can someone who is not part of the scrum team also be an inspector?

Yes

Like a project manager or someone from management in the organization.

Maybe.

Now let me explain.  If your Development Team is working on some technology that is new to them but there are people in your organization that have experience with it, then I would encourage the Development Team to involve them in the inspection so that they can learn from those people's experience. But I will caution you to avoid creating a situation where all work done by Scrum Teams have to be "signed off" by a group of people outside of the team.  The Scrum Guide states the following in the section describing Sprint Planning

The Development Team may also invite other people to attend to provide technical or domain advice.

It would make sense that those same individuals could be used as inspectors as work is done.

Now for your second statement.  If the Project Manager or someone from management has domain knowledge of the work that is being inspected and the Scrum Team asks them to participate, then there is nothing in Scrum that says no. However, again be careful that you are not getting into a "sign off" trap.  Their feedback should be used exactly the same as any of the Scrum Team and their feedback does not carry any more weight.  They are invited to help the team not allowed to manage the team. 

Naredla - I am newer to this terminology, but my understanding is during the Sprint Review, managers can be part of that review process.  On our teams, we all inspect in our "specialized" areas. I am not a coder so I cannot inspect code, but I can expect the outcome of the code - for example the data that should be on a report. I think it is important to be creative and flexible work closely on the team to understand best what the deliverable will be for the Sprint Review.

Can someone who is not part of the scrum team also be an inspector? 

Like a project manager or someone from management in the organization.

If those managers are stakeholders in the product, and are not trying to manage the team, then potentially they could be inspectors.

The Scrum Guide says:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.

...

Attendees include the Scrum Team and key stakeholders invited by the Product Owner

Thank you very much for your suggestions. I have cleared PSM 1 with 97.5%.