Team velocity is a scrum metric that shows how much work a team does per sprint. The amount of work, as you remember, is measured in story points. Therefore, instead of the usual km/h, we will use SP/sprint as the unit of velocity.
We need to predict the speed of the team to understand which stories from the product backlog we can schedule in the sprint, and which ones won’t fit into it. The same speed of the team is needed to calculate how many sprints (and hence the time) it will take to do part or all of the backlog.
At first glance, it seems that to predict the speed you just need to multiply the number of people in the team by the duration of the sprint (in working days). Ideally, that would be the case. But in reality, a team does not achieve this speed. The fact is that statistically, on average, a person spends about 4 hours on an 8-hour workday to get things done. The rest is spent on meetings, smoke breaks, visits to the toilet, communication with colleagues, distractions, tea/coffee, rest, etc. In addition, there are equipment malfunctions, illnesses, time off, absences, and other sudden events that affect the team’s productivity.
In companies that don’t take this into account and plan work based on ideal man-hours, this can be one of the reasons for regular problems with not meeting planned deadlines.
The productivity of scrum teams is usually above average. That’s why the recommendation for planning the first sprint is to take into account 70% of the team’s resources, not 50%.
Team Velocity.
Used for planning subsequent sprints.
The predicted speed is the sum of the scores of the planned stories (points)
Actual speed – the sum of evaluations of completed stories (points)
After the first sprint is finished, you can calculate the actual speed of your team. To do this, you must add up the scores of all the stories finished for the sprint.
Here it is important to pay attention to two nuances.
First,
completed stories are only those that meet the Readiness Criteria at the end of the sprint. For example, if a story is 90% complete and does not meet the readiness criterion, the completed stories will not count towards the actual speed. They will be fully included in the speed calculation of the sprint where the story will be ready. Most likely it will be the next sprint.
Thus, partially completed stories reduce the actual speed compared to the predicted speed, but completed stories from previous sprints increase the speed.This principle is easy to understand if you remember that the main unit of benefit in scram is the story, not the story point. If you implement a lot of story points, but you don’t finish a single story, it’s the same for the customer as if you’ve done nothing at all.
Second,
the sum of scores is not the same as the sum of actually spent story points. Often when mastering scrams, one makes this mistake. They think that since it’s about actual speed, you should just look at how long it took in a sprint to complete all the finished stories. That’s not true. Let’s break it down with an example. Suppose when planning the sprint, the story was estimated at 5 SP. During the sprint, it took 7 SP. To calculate the actual speed, you should take 5 SP, not 7 SP, which is an EVALUATION.
This seems counterintuitive at first glance, but it makes sense. In this way, the error of the estimate is also taken into account for later planning. It doesn’t matter if your team tends to underestimate work on average or, conversely, over-estimate. Both will be taken into account since the calculation takes into account exactly how many of its planned story points your team can realize in a sprint.
Of course,
in the first sprint, your team may show higher or lower efficiency, not 70%. This factor is called the focus factor in the scrum. The reason for this name is that it is a measure of the focus, the team’s focus on the execution of stories. The more the team splits up on other things, the less focused the team is on the sprint.
