Team delivers Value but burndown charts are not looking good , how to "solve"?

It's a bit confusing if you say that a problem that you want to solve is that burndown charts don't look good but the reports aren't honest. Which is the problem? Honest and transparent reports don't always look good. If you're going to produce some kind of report or visualization, the most important thing is that it is clear, understandable, and accurate, even if it doesn't look good.

However, the underlying problem appears to be how you are planning the Sprints. Why is the team pulling in so much work? I'd want to understand why this behavior and try to eliminate it. The team should base their decisions on how much work to bring in on recent past performance and a forecast for their capacity for work in the upcoming Sprint. Pushing, being optimistic, or bring unrealistic doesn't help the team communicate what they are working on and what is likely to be delivered to stakeholders.

our PO and Dev Team always feel the desire to push a bit extra or be optimistic from the very early stages of our sprint which creates sometimes an unrealistic scenario in our metrics

Why they wanted to push extra and why they don't care about the progress of it ? 

its basically items we decided to push into the sprint and work on even a bit.

There's no value in starting work. None. Value is only released by finishing it. That creates capacity so new work can then be pulled and finished in turn.

Once you have a demonstrable flow of finished work, the measurements become truthful and useful.

The goal of a Sprint is to have work meet the Definition of Done and be ready to release.  Pulling in work with no intention of finishing it is not a good idea.  For one, it creates a false sense of accomplishment and also inaccurately illustrates what work can be "done" during a Sprint.  Story points are honestly worthless after work begins and should not be used as a means of indicating the amount of work accomplished.  By doing the practices you indicate, the team is hurting themselves.  There is no ability to provide any reasonable forecast of work and they are not creating a "sustainable pace".  

I have seen teams fall into these practices and it evolved into a very bad place where it became "okay" to get any work "done" and releasable.  As a Scrum Master I encourage you to help them understand the difference between working on something and completing something during a Sprint time box.  

If the team are not completing all their work then talk about the Carry-Over during the Sprint Review and Sprint Retrospective. 

Does the team have time for tech dept, defects and learning throughout the sprint? if not then they will burn out. Ask the team in the sprint review how they feel about those 3 and if they think it's worth trying and the costs of no doing these 3.

Get to the root cause using something like the 5-Whys. This may suggest that there is someone in the team pushing to keep "busy", this is not the goal.

To give you an example for this sprint,  we have 60 points completed and approximately 120 left as WIP but it isn't bad - its basically items we decided to push into the sprint and work on even a bit.

Some practices to consider 

• Limit the WIP
• If the team is committed to N number of points, educate PO not to add more stories
• once the team is completed (on whatever committed) and if they have time, pull the next high priority story

How your Sprint Goals looks like? IMHO there may be a problem with focus on what is important and seeking ways to be occupied by work from “my” area of expertise, therefore you push more PBIs into the sprint and “work a little” on them. I would argue that you should assess with Scrum Team your Sprint Goals and maybe start using them differently than you probably use it now? 🤔

You say "in this role", which role? 

I would consider this a bigger problem than is implied in the OP.

It is important to have a clear idea of what work the team can complete (and that's 100% complete: tested, accepted, documented etc). During "peace time" this might not seem that important. But inevitably there will be stresses like an external deadline, several members of the team being on holiday, or a "give" requirement to align with another team etc. During times like this, you really need to have a good idea of what your team can actually deliver and for that you want to have a history of making realistic and progressively refined estimates.

So I would put my foot down on this one and consider it a big flaw if too much work is being pulled into a sprint. Remember, you can always pull extra stories into a sprint if any team-members find themselves with no remaining work (but I find this rarely happens in practice).

So: imagine if the team pulls in 30 story points of work in the first sprint and only completes 20 points (and remember: 100% complete). Well, next sprint you plan for 20 story points, and that's that. If anyone questions why, you point to the first sprint.

Forget the Burndown chart unless the team is under their own pressure and working on too many things at once.

If the team is delivering value and meeting the Sprint Goals as a team and without getting stressed and working long hours then leave it be.

Remember that the Burndown is only a guide, it can show too much WIP or that items are too large, if this is not an issue for the team then just drop it. 

Also don't show the Burndown to anyone outside the team.