Welcome back to this Scrum course. In this lesson we are going to discuss Agile velocity. The velocity is the team's estimate of how many story points they can complete in a sprint. In other words, it's their capacity. Velocity is considered to be almost a long-term type of metric. It is averaged over time. Teams typically validate what's called their capacity for each sprint. A capacity would be based on the team's current resources. There could be team members that are either unavailable, some are part of the sprint, there could be team members that are out. It's a good idea to prevent velocity degradation to just estimate what the current capacity would be sprint to sprint, and that is a best practice for most Scrum teams. Again, capacity is a metric, that does prevent velocity degradation from the ebbs and flows of team variability, team availability. Velocity is just only a planning tool, so don't fall into the trap of velocity is a team's productivity or rating. Not the case. It is only an estimating tool. Teams use their velocity as the upper limit of how much they can deliver in a sprint, and teams should be encouraged to plan up their velocity but not beyond it. Velocity is again not the team's productivity, and not the team's rating, not the team's effectiveness. It is strictly just an estimating tool that the team needs to fairly plan on what they can deliver, and to make sure they can deliver a working solution increment, by the end of the sprint. It's important again, that the management, the team, the Scrum master, the product owner, does not overthink, or get caught up in that velocity. Velocity is historic. No question about it. It's based on past performance, and the team uses its past performance to estimate what they can do in the upcoming sprint. However though, what can a team use if they are on the very first sprint? If they're on Sprint 1, there is no past performance. Once they get to Sprint 2, they will have a past performance, but when estimating Sprint 1, there is no past performance. But the Agile community actually has a little rule, that can be followed. Works for teams of all sizes. The team goes in, and just looks at the team members. In this example, developers, testers, business analysts, documenters, anybody who's contributing toward the deliverable. The delivery owner, or the product owner, the Scrum master, they're not building the product. There are obviously important roles, but they're not building the products. We don't look at their contribution in this estimate, but what we say is, each team member provides, approximately eight points for a 10 day sprint. If we look at this example here, if we have three developers, that's 3 times 8, that's 24 points. If we have one tester, that would be 8 times 1. We could say our initial normalize, because all teams are going to be doing this. Our initially normalize velocity would be 32. Whether that's high or low really doesn't matter, because as we go into Sprint 2 and Sprint 3, we will have a past performance to base our velocity on. Again, tracking velocity. We just track our velocity sprint to sprint, and in general, the Scrum community, does prescribe that velocity be averaged of the previous sprints. It's up to the team. The team can use it's recently concluded sprint, or an average. Most products will offer a report with an average velocity. The average is a good practice, because it can smooth out some of the bumps that are encountered in some of the sprints. Some teams also only use their previous sprint, and attempt to slightly better their velocity each sprint. As the team matures, they get a really good feeling about what their velocity is, and they might even try to test it a little bit by taking on, just a pointer to lower, then their current velocity and teams will do that. It's not a practice that's encouraged in the beginning, but as the team matures, they can certainly test their limits. Again, the average of the velocity, it can be a rolling average. It's typically calculated as a rolling average. It's sometimes out of the last five, or out of the whole sets of different sprints. They drop the first one, they drop the recent one, and then average everything else. That tends to be a popular way to go and a lot of reports, a lot of products will calculate velocity in that way. That's our velocity lesson, and thank you again for watching it. In our next lesson, we're going to discuss backlog refinement.
