How to calculate Schedule Variance in Scrum with story points?

Question

I am trying to find a way to calculate the schedule variance for the scrum. I was trying to found a similar question here on StackExchange, but Yet I didn't found any. So I have posted it here.

Below is how we count the schedule variance. For example, If a sprint has 3 stories and each has 5 story points. Only 2 stories get completed at the end of the sprint, then The Schedule Variance would be 66.67 (10/15*100).

Is this a good way to go with the calculation? Or do we have any other way to calculate schedule variance in scrum?

Answer 1

What you're trying to do makes no sense.

Scrum doesn't have the concept of a project schedule. In Scrum, each Sprint is a timeboxed activity that could be viewed as a project. At the end of the timebox, work is either done or not done. You deliver at least one potentially releasable Increment every Sprint. The only variance is in the scope of what is delivered and rarely, if ever, in the minimum frequency of delivery.

I would recommend assessing why you wish to use schedule variance. I do not believe that it is appropriate for situations that Scrum, and other Agile methods, are best suited. Agile methods are best used when there is a good deal of uncertainty. With uncertainty, it's not effective to make long term plans that you would use to calculate variances against.

Answer 2

I agree with the comments already made. Velocity seems like a better way to measure performance and maybe an example will help.

Suppose a team, for whatever reason, over-committed themselves at sprint planning. Their regular velocity is, say, 50 points, they forecast 80 for the current sprint but only delivered 75. Your method would show that as a schedule variance of 94% even though they increased their velocity by 50%!

Now suppose the team only forecast 40 points. If they deliver 40 points as forecast then that's 100% by your measure even though their velocity reduced by 20%.

Velocity is what allows you to forecast delivery on time. Looking at variance for one sprint in isolation is perhaps a useful thing to do in sprint retrospectives but looking at the trend on a burn chart is much more valuable.

Answer 3

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.

Answer 4

Not sure how much I agree with the other answers, However If you trying to predict and end date and you are using Jira, have a look at the epic report.