Whilst I’d advise against it - Yeah, I’m definitely a purist 
- I expect this would help you work the way you want to work:
- Create a backlog project, with a story points custom number field and add that to the field library
- Create a product portfolio, and add the backlog.
- Create a sprint project, and add the story points field.
- Add a burndown chart in the dashboard tab of the project.
- Also add this sprint project to the portfolio.
- Add a rollup field to the portfolio, and choose the story points field.
- Multi-home the backlog items into the relevant sprint.
- Duplicate the sprint project without the tasks every sprint. (I’d normally advise using a template, but sadly Saved view tabs to be supported in Project templates isn’t a thing yet, and I assume re-creating your dashboard every sprint would be unacceptable.
I’m sure the portfolio dashboard will give you some options to track the story points across sprints, and calculate velocity with a formula.
This is a bit tricky indeed. Scrum seems to have a different meaning when you look at what’s most commonly meant vs what’s in the Scrum guide.
And eventhough you are of course free to pursue whichever way of working you choose, as an improvement professional I feel I should add this context and challenge the sense of adding features to support this out of the box, especially when calling it Scrum.
If you’re open to some more soapbox advice:
- Have one sprint goal per sprint, and name the sprint project after it.
- Also make this a milestone, and add all work needed to achieve this as blocking. The idea is to add the minimum amount of tasks needed to achieve the sprint goal. (And don’t go cheating by calling “complete all work in the sprint”.
Make it a meaningful increment of value) - Don’t add any work that endangers achieving the sprint goal.
- Have a custom field at the portfolio level where you track whether the sprint goal was achieved or not.
- Use the status update feature during/after the daily Scrum to reflect on whether you are making meaningful progress to achieve the Sprint goal. (Which I think is a lot more meaningful than the 3 questions most seem to use)
Because in the end I think it’s more meaningful to be reflecting on whether the team is effective in delivering increments of value than it is reflecting on the velocity compared to the last sprint.
/steps off soapbox