Summary
In general, the Scrum framework is concerned with whether or not the Scrum Team can predictably meet a singular Sprint Goal each iteration rather than in "schedule variance." The goal is predictability of goal delivery, not time efficiency, although the two are not unrelated.
Rather than measuring schedule variance, your team should be measuring whether or not the Scrum Team is meeting its Sprint Goals more often than not. This metric can be pegged to whatever degree of predictability the organization requires, but 80% Sprint Goal success is a common and broadly achievable target.
Analysis and Recommendations
Schedule Variance Isn't a First-Class Scrum Metric
I am trying to find a way to calculate the schedule variance for the [S]crum.
"Scrum" is a framework, while the "Daily Scrum" is a mandated event that takes place during the Sprint. "Sprint" is the name given to a time-boxed iteration within the Scrum framework, and each Sprint has a Sprint Goal that provides a unifying objective to the work done within the iteration.
You can't have schedule variance for a framework, and in general "schedule variance" isn't a useful or meaningful concept within the Scrum framework since estimates of work, effort, and time are estimates rather than money-back guarantees. A specific Sprint Goal is either met or unmet; it is a strictly binary result, and cannot be only partially met. As a corollary, that also means that work planned for the Sprint is either done or not-done, and measuring the percentage of work completed during the Sprint is irrelevant to whether or not the unifying Sprint Goal was met.
Achievement of the Sprint Goal Is a First-Class Metric
It is possible for the Sprint Goal to be met without 100% of planned work being completed. It is also possible for 100% of the planned work to be completed, but for the Sprint Goal not to be met. Therefore, the correct measurement of a successful or unsuccessful Sprint is primarily whether or not the Sprint Goal was met, not measuring the deltas between planned and actual values for individual pieces of work.
Measuring Other Types of Variance
If you are trying to express schedule variance in relation to the release planning for a product, you can only do that with accuracy after the fact. More proactively, you can compare the team's current velocity and the estimated work remaining to set expectations for particular milestones.
In addition, if you are using story-point estimates and want to express the delta between planned and consumed story points, this is possible but generally considered an anti-pattern. It's an anti-pattern because it shifts the focus from the binary state of the Sprint Goal to measuring "effort expended," which might be useful in refining the Scrum Team's estimation techniques but completely useless in determining whether a Sprint Goal was met or unmet.
Fill Time Boxes with Work Related to the Sprint Goal
The goal of a Sprint is to meet the Sprint Goal within a given time box, not to complete specific work items worked to a planned schedule. The Sprint itself is an ephemeral time box during which a defined goal may or may not be achieved. The Scrum framework does not treat the time box as a schedule, nor mandate how work should be scheduled by the Developers within the Sprint. Furthermore, work that is unrelated to the current Sprint Goal should not be scheduled at all. Note that architectural runway, chores, refactoring, and performing elements of the Definition of Done are related to the Sprint Goal, and therefore belong on the Sprint Backlog but still not "scheduled" in the traditional sense.
So, the notion of "schedule variance" within a Sprint or within the Scrum framework is based on a misunderstanding of the how the framework should be applied. This is most likely an issue where "work" is being scheduled and assigned on an individual basis the way it is in non-agile frameworks.
Leverage the Sprint Retrospective and Avoid Proxy Metrics
Use the Sprint Retrospective to determine the underlying thing you really want to measure as a team. It is unlikely that schedule variance is the objective; it is most likely just a proxy metric intended to measure something else. Figure out what that "something else" is, and the work together as a whole team to determine the best way to measure and report whatever the real tracking item is.
Whether schedule variance is a proxy for release planning, productivity, or simply an attempt to improve estimates or hold people accountable, it's still a proxy. When possible, always measure the thing you actually want to manage directly. Proxy metrics are leaky abstractions, and rarely capture the intended data or lead to meaningful change.