TL;DR
Your board is out of their collective gourds. Estimates are not guarantees, and the precision of estimates in any process (but especially in iterative processes like Scrum) is a function of both inevitable change requirements and a varying cone of uncertainty.
Estimating Epics
The purpose of estimating epics is to give a rough outline of the project schedule, and allow stories to be prioritized to achieve optimal value for each milestone or target ship date.
By the very nature of epics, the cone of uncertainty is extremely large and the initial estimates (which are not guarantees) will not have the precision of the story-by-story estimates that are done at the start of each Sprint.
Project estimation is a projection, and a guideline for measuring variance. The project schedule can and should be subject to the same inspect-and-adapt cycle as the rest of your process. The board can then use the Theory of Constraints to adjust schedule, scope, or resources as they see fit.
Inspect-and-Adapt Scheduling
Are the story points related at all between initial estimate and later sessions?
Yes and no. Ideally, while there may be variance between the initial projection and iteration-by-iteration feature delivery, the variance should fall within some reasonable order of magnitude. If it doesn't, which is not an uncommon occurrence, then it is simply evidence that the initial estimate was wrong and should be revisited.
Another way of looking at this is that the initial estimate is a baseline against which you will identify variance. What you choose to do about that variance is up to you. In a well-run Scrum project, one might:
- Re-estimate the entire Product Backlog in light of what is currently known.
- Re-estimate the project schedule based on the new backlog estimates and the team's current velocity.
- Re-prioritize the Product Backlog to squeeze as much value into achievable release dates as possible.
- Fail early, if the project's objectives cannot be met.
Identifying Variance: Effective Control Isn't a Sin
The real problem here is cultural. You have a command-and-control project board that is looking at iterative development as a silver bullet. It isn't.
Identifying variance is a desirable outcome of an effective project control. Punishing the messenger does not result in transparency or visibility; it can only result in CYA behaviors such as:
- Excessive padding of all estimates.
- Project dashboards that are always green, right up until the project results in an irremediable epic failure.
- Ponderous change management controls designed to prevent any changes which could increase the cone of uncertainty by even one iota.
- Blame-shifting, including finger-pointing to poor specifications or vague project criteria, neither of which will result in a usable product.
The purpose of comparing your current progress against an initial or updated scheduling estimate is to identify that variance. If variance is punished, then it will not be identified. Q.E.D.