Velocity is the speed of the team’s work. As a rule, the average for the past 3 sprints is used.

4 frequent questions about his calculation (the term Product Owner is used here, but it can be any other similar manager, no matter what he is called in a particular situation):

  1. If we have a task for 4 SP, and according to the developer’s assurances it is 90% complete, is it taken into account in the sprint? At least partially, didn’t we work and almost finish it? No, it is not taken into account, because the task (story) is already the minimum visible value for users: if it is not done, then there is no value, which means there is nothing to consider. If it turns out that it is still possible to break, then this is a lesson for the future, current tasks are not broken.
  2. After the start of development, it became clear that the task was more difficult than it initially seemed. Is it possible to change the rating? No, because the assessment is to improve forecasts for the future: with a high probability we will make the same mistake again and this will already be embedded in our speed. Let’s not make a mistake - the speed will increase, it’s also good that we learn from mistakes and become better as a team, but this needs to be proven infallible in the future.
  3. After the start of development, it became clear that the task was much more difficult than it initially seemed. For example, a month instead of 1 day. What to do? Also, do not change the rating? No, the task needs to be canceled, then it adds 0 SP to the sprint. Perhaps, if it is something important, then the entire sprint should be canceled (restarted). Let the Product Owner already decompose and prioritize anew, then assessments will be made for new tasks.
  4. Should bugs be measured in SP? How to take into account how long we will fix them - we don’t know in advance? Bugs are not measured in SP, because this is not a story by definition. The Product Owner determines whether to include bugs in the current sprint or not. If the bug is enabled, then it is prioritized above any stories (whether or not to interrupt the current stories is a separate moment). In fact, these are remnants from some previous stories that slow us down. It’s right that they slow down the speed by not taking them into account. They are already registered in the SP of those tasks that they did before. In other words, we do not need to try to “close” the tasks if we understand that there are still many bugs: they will quickly return and affect the speed. Some spikes are compensated by the fact that we average velocity for the purpose of understanding how many stories we can take in a sprint.
  5. We want to include several sprint bugs when planning it. It can take almost half a sprint. Are we still not taking them into account? Here the principle is the same as with stories: if these are ordinary bugs, then we do not take into account, if something extraordinary (for a month +), then it becomes a story with all the ensuing consequences. Yes, the speed will drop and this is adequate, because it means that it was overestimated before. How to determine exactly how many tasks to take in a sprint? According to the consensus of the team: ask “will we do the first 8”? Yes. And 20? Hardly anymore. 15? Yes, it should work, but it’s unlikely anymore. That’s where we stop.
  6. But these are old bugs from another team, and we’re wasting our time on this. Let’s take them into account in the sprint. No, because I’m not interested in the conditional “pure” performance of the team, but how many features it can make. Individual bursts of bugs are averaged at a rate of 3 sprints.