Release Burndown Chart - Story Points

It's important to preface this by saying that story points and burndown charts (whether at the release level or otherwise) aren't part of the Scrum framework. You'll probably find many people with many different ideas on if and how to use them.

I'll start with a high-level question: How do you know you have 3 releases and 2 iterations per release?

The concept of a release burndown chart implies that you know something about the release you are burning down. This could be the number of Product Backlog Items or the size in story points of Product Backlog Items. However, it's a trap to believe that you can forecast what your release will look like in a few iterations. Feedback from a Sprint Review could result in releasing earlier than you had expected or otherwise changing the scope of what makes sense to release, for example. Even doing work during the course of a Sprint could result in changes to the Product Backlog and what you intend to have as part of your next release.

At best, a release burndown will only reflect what you believe to be true at a given moment. Refinement (which may or may not include estimation), Sprint Review, and designing and building the solution can cause you to add, remove, modify, or learn more about the work required to make a viable release.

To avoid the issues around refinement, you could consider using a raw count of Product Backlog Items as the thing you are burning down. It doesn't resolve issues about what happens if you discover new work, a Sprint Review reveals new stakeholder needs, or your refinement results in breaking down a PBI into smaller PBIs. It does resolve the issue about unestimated work, though, and these other problems are not new.

Another alternative would be to shift away from the planned release mindset. Focus on ensuring that the product is always in a releasable state, after every Product Backlog Item is implemented. If you know the changes between the current releasable state and the last released version along with information about your cost to release, you can determine if it makes sense to release after any individual PBI is complete.

Assuming I have 3 releases and 2 iterations per release. Is it normal that during my 1st release  I have less total story points than my next two releases shown in my release burndown, because not all user stories in the product backlog have been assigned story points yet.

In Scrum the only purpose of estimation is for the Developers to get their arms around how much work they can take on in a Sprint. Everything else reduces to value delivery and empirical process control. You want to minimize the risk of the size of the work being the size of the wrong thing. My advice, therefore, is to think a bit less about burndowns and numbers, and rather more about validated learning, and how you get empirical feedback at least once each and every Sprint.

What does your Gantt Chart show?  I ask because you are describing waterfall project planning and not Scrum.  In Scrum you can have a forecast of work that might be done in the future but it is just that. A forecast.  Much like the weather forecast, it is likely to change especially the further out it goes.

Scrum is valuable when you have a complex environment with frequent changes that require adaption.  Using empirical controls and practices, each Sprint is a project of it's own and could result in a release.  In actual practice, I have worked with teams using Scrum that did Continuous Integration/Continuous Deployment to production, sometimes multiple times a day.  The benefit of Scrum is that you do not have to plan out the future because you will be adapting to it as it unfolds.  

Assuming I have 3 releases and 2 iterations per release

Let's assume you are using the typical Sprint length of 2 weeks.  (2 iterations X 2 weeks) X 3 releases means you are looking 12 weeks into the future.  A lot can change in 12 weeks in the world today.  Are you sure that what your stakeholders wanted last week is what they will need 12 weeks from now? If so, then Scrum might not be the best solution for your organization.  

I concur with Thomas Owens response.

Moving away from strictly using story points and release burndown charts, as prescribed by Scrum, can offer more flexibility in agile project management. Emphasizing a continuously releasable product state rather than adhering to a fixed release schedule can enhance a team's ability to adapt to change and stakeholder feedback. This approach focuses on the completion and value of Product Backlog Items (PBIs), rather than on detailed estimations and rigid plans.

Considering alternatives, such as tracking progress through the raw count of PBIs, simplifies the tracking process and avoids the pitfalls of estimating work that might change. It shifts the priority towards delivering work items and maintaining product quality, allowing for releases at any point based on the added value and stakeholder needs. Ultimately, adopting a more fluid and responsive planning strategy aims to keep the product in a state that is always ready for release, ensuring agility and the continuous delivery of value. This method encourages moving from detailed forecasting to a focus on adaptability and immediate value delivery.

@Annah

Moving away from strictly using story points and release burndown charts, as prescribed by Scrum, ...

Could you point me to the location in the Scrum Guide(https://scrumguides.org/scrum-guide.html) that prescribes strictly using story points and release burndown charts? 

As for the rest of your post, I really have nothing to argue. I have advocated for the same thing on many occasions.  But I would like to know where you gained the knowledge of story points and burndown charts being prescribed by Scrum.