0

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?

| improve this question | |
  • 3
    What are you trying to achieve? With your approach, you will get a series of meaningless numbers, and it can't be fixed by using a different calculation method. The Scrum process favors analysis of the sprint quality through the retrospective, which means human judgement by all team members instead of analyzing numbers. – Hans-Martin Mosner Apr 28 at 6:53
  • 1
    Scrum does not have schedule or cost variances, right? It only has a scope variance: what did not get done goes back into the backlog and your adjust your burn down charts accordingly. No? – David Espina Apr 28 at 12:00
  • 1
    The points others are making are valid. Schedule Variance is only meaningful when you have a fixed scope and schedule. Scrum is designed for problems where this is not feasible and you need an adaptive approach. That said, the underlying need of understanding how things are progressing is still valid and I would recommend looking at burnup charts as a common tool for gaining that visibility. – Daniel Apr 28 at 16:26
3

What you're trying to do makes no sense.

The first problem is that story points have no relation to time. Story points are a measure of effort needed or complexity. Something that requires a lot of effort may be something that can also be done very quickly. However, something that is estimated to be a very small amount of effort may be done with the same amount of working time or much longer. You simply can't compare an estimate of effort or complexity to time.

The second is that 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 appropriate. 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.

| improve this answer | |
1

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.

| improve this answer | |
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.