What is the best way of publishing a scrum status project to the sponsor

What does the Product Owner think is the best way to keep stakeholders, including the Sponsor, appraised of progress?

For example, does the sponsor care about the increments which are being released each Sprint? Are they providing the kind of production value the sponsor would like to see? If not, why not?

The product owner talks about value delivered for the sprint completed and for the PBI to come he talks about sprint not about points by PBI to the stakeholders but for the sponsor
this is the sc;rum master which does the report and the scrum master want to talks about
points by PBI to come.

The sponsor cares about the value delivered each sprint but he wants to know if the project will be completed by the date he has signed with
his client and he wants to have a detail report on the situation on regular basis.

My concern about doing report to the sponsor using points by PBI by team is that points is a value with a different amount of work by team.

By the way I am not the scrum master who does that report, I disagree about using points by PBI by team and I like to have some ideas/ suggestions about that.

Thank you

Did you suggest publishing the number of PBIs completed in each sprint? It is not linked to the Story Points and BTW creates a subtle encouragement to the team to generate smaller stories :)

You can be transparent about the total size of work that is thought to remain in the Product Backlog. A Product Burndown showing the overall burn rate (in points) for all of the teams is one way of doing this.

How many points each team forecasts for completion, compared with another team, is immaterial to the overall work remaining and any projections made. The estimation and planning of how much work a team can do is the business of the teams themselves.

So, the sponsor cares about the value delivered each sprint from the perspective of when will the project be completed.
He needs to know the pace of the team, so he can make a projection of the pace to the amount of the work remaining in PB.
Points as a unit of measure should be ok, if you help him/her to convert the points to man-hours, timeline, and cost. As suggested by Boris, publishing the historical records of how many points were completed in prev sprints - should help a lot.

The fundamental problem is "he wants to know if the project will be completed by the date he has signed with his client and he wants to have a detail report on the situation on regular basis." Did he guarantee not only a date but a full slate of features? Do the PO and sponsor understand that every software development project is unique and unpredictable? Software can be duplicated: we don't "build another of the same."

Even with a routine, follow-the-recipe, non-software project, the existence of task dependencies tends toward late delivery. With two dependent tasks there are four combinations of [I]on time/not on time[/I], and three of those four make you late. Now scale that up: any hiccup makes you late unless you have a massive, protected contingency.

So the big problem is not how you report status -- it's that your status is not a promise. (Read the Dilbert strip here: http://dilbert.com/strip/2016-12-21.)

Velocity, PBI counts, points are all indicators based on past performance with different challenges, but they do not guarantee future performance. Show me a team that maintains a perfectly steady velocity and I'll show you a team that fudges their numbers.

I hope they have a great risk management plan with lots of contingent items they can kick to the curb and still get paid. If they don't, the scrum master might want to make sure the PO understands the risks and how best to mitigate them, so that the PO can work with the sponsor on those contingencies.

If you're not transparent, you're not doing scrum.