## Introduction

In most of the Scrum sprints the Scrum Team complains about the inefficient or underestimated (or perhaps overestimated) story points, which results in wrong capacity planning and consequently a lot of pressure on the team in the last days of the sprint.

Therefore, refining the process of estimation and planning would help the team work more efficiently and with much less stress and deliver a better product at the end.

The following discussion and the to-be-presented approach is useful for all Scrum Team members such as Scrum Master, Development Team (including the testers and designers), as well as Product Owner. In addition, in case there exits a Project Manager involved, this approach can help him/her for a better understanding of the planning and for a better follow-up during the Sprint.

## Model

Imagine two friends who have to walk separately from point A to the point B; both points are clearly determined and known for both of them. They are discussing about meeting each other at point B. One of them says it takes 10 minutes to reach to the Point B, but the other insists that it takes only 5 minutes; they have such a conflict that they cannot reach to an agreement. Even if they agree on a value in between, let’s say 7.5, this is still not the correct value for either of them. The question arises here why it is difficult to reach to an agreement.

Meanwhile, a friend of theirs joins the discussion and offers a new approach; to find a new measurement which can be agreed upon by both persons. Their friend asks if they have any idea about how far it is from point A to the point B; both can answer a unique value, for example 55 unit far, which can be in meters or any other unit.

Therefore, the only measurement, which stays the same for both guys, is the “distance” between the points. So we can logically conclude, that the distance is the unique measurement for both guys, which is here 55 meters, but it takes one of them 10 minutes and the other one 5 minutes to walk from point A to the point B. This means, they both take the same distance but in different timings, which is defined as “time”. The reason that their timing is different is because of their different pace, which is their walking speed, i.e. “velocity”. Therefore, nearly always during the estimation in scrum planning, the developer team also consider their own pace (velocity) in estimation, which lead to the wrong capacity planning.

Let’s recapture a formula we studied at high school in physics and try to better understand this behaviour: **distance (d)= time (t) * velocity (v) **

We use this formula nearly everyday when we drive a car or a bike or if we want to reach to an appointment or even in each moment during walking, our brain calculates the distance and/or timing with the help of this formula, so that we do not hit someone or something. Therefore, this formula easily applies to the nature and of course to the reality.

In this article, we want to adjust this formula to the scrum sprint planning, and if we assume that the velocity with regard to time is linear, i.e. **v'(t)=****0** , the following generic formula should be taken into consideration:

Before discussing about how to find the velocity median **(ṽ)**, we should point out that in this approach, during the scrum sprint planning and more specifically during the estimation, the developers should estimate the story points ONLY based upon the so-called distance or in better words based on the work volume, and they should not consider their own speed/pace/velocity in the estimation. Therefore, we need to know how to calculate **ṽ**.

The velocity median can be easily calculated according to the data from previous sprints, which represents the “team velocity” and not the individual one. In this approach, this so-called “velocity median” is actually the “correlation coefficient”, according to Pearson correlation, which can be calculated with the following formula for the population:

Besides, to find the correlation coefficient (velocity) of the sample, which is what we consider for our optimization, the following formula applies:

Therefore, after finding the sample correlation coefficient of d (story points) and t (time spent on the stories), we can find **ṽ **– the velocity of the team. And now, we can use this value for future planning. So the final formula for finding the available time for the upcoming sprint will be:

## Conclusion

It is to be mentioned that in this approach, the buffers, sunk time because of meetings as well as other incidents, will be indirectly included. However, the Scrum Master as well as the Project Manager (if there exists any) should also keep in mind to consider the official holidays and vacations of the team members, in order to reach to better optimum figures. It should be noted that the more data included in the calculation, the better estimation can be expected. The Scrum Master and the Project Manager should also be careful of the outliers in the data.

## Reference

[1] https://manifesto.co.uk/how-to-measure-velocity-agile/

[2] https://www.scaledagileframework.com/iteration-planning/

[3] https://www.versionone.com/agile-101/agile-management-practices/agile-scrum-velocity/