As the target of what to include in a release is not fixed, I generally prefer to create a release burn-up chart, rather than a burn-down chart.
A release burn-up chart shows on the horizontal axis the sprints and on the vertical axis the story points that have been completed/estimated. It also has (at least) two lines on it:
- A line representing all the work considered for the release, with a projection into the future assuming the total amount of work remains stable
- A line representing the work that the team has completed so far, with a projection into the future of how much work the team can complete based on the average velocity. If you want to be really fancy, you could add a cone of uncertainty around this projection to indicate that variations in velocity have an impact on the projected release date.
After each sprint, you would update the chart with the most recent values for the total size of the backlog and the porting that the team has completed. If you do this for a longer period of time, you will see that the total size of the backlog will fluctuate, because features get added/removed and story estimates get revisited. This is entirely normal and should be valuable information to your project-manager.
To answer your specific questions:
If I have epics that are not broken up into stories yet, how do I add them in the release burn down chart
If the epic isn't broken into stories yet, then you should estimate the epic as a whole. The uncertainty on the estimation will be bigger, but that is not a problem. When you get around to breaking down the epic, the estimates have to be revisited anyway.
If I stories where the team does not have the knowledge yet to compete the story, how many points do we give them?
Who assigns points to the story? Me or the team? How can I/they assign points if they do not yet have the skills to complete the work?
The best estimates come from the people who will do the work. This holds even if they don't yet have all the knowledge yet to actually do the work. The only thing is that the estimates will generally be more conservative (i.e. higher) because a larger risk-buffer gets included due to uncertainty.
You shouldn't spend too much effort in getting the estimates for stories/epics far in the future to be accurate. One rule to keep in mind is that estimates can always be revisited/changed in Scrum. Only after you have taken a story into a sprint should the estimate be considered to be fixed/final.