Velocity is one of the key components necessary for managing successful Agile Web development sprints. The ability to precisely calculate and track a team’s velocity will make the process of planning and managing a sprint a more pleasant and efficient experience for both the project manager and the Web design and development team.
What exactly is velocity?
Simply put, velocity is a number that represents how much work, or points, your team can complete in a given sprint. For the purpose of this article, let’s assume the number of points are equal to the number of hours the team has available for the sprint. If our team is capable of working 70 hours a week on a given project, a month long sprint would have a velocity of 280 — that is, 280 points worth of stories we can include in the sprint.
Here is how the Scrum Alliance defines velocity:
In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning. Once established, velocity can be used to plan projects and forecast release and product completion dates.
How can velocity computations be meaningful when backlog item estimates are intentionally rough? The law of large numbers tends to average out the roughness of the estimates.
How do we calculate our velocity?
Those who are new to Agile Web development may not be able to accurately calculate velocity just yet. That’s OK. We can guess. What’s more important is that we estimate velocity and track it going forward, preferably using online time tracking software, and refine it as we go. By tracking your team’s efforts in units of time you will start to see quantifiable trends and patterns that can be distilled down into our velocity.
To get started tracking our time to calculate our velocity, we need to plan a sprint. Create a list of tasks we’d like to have completed in a one month time frame. As our Web designers and developers work their way through the list of tasks, we accumulate time tracking data unique to that sprint, but definitive of our team’s throughput, or, velocity.
Once the sprint is completed, we divide the number of hours by the number of weeks and that is our velocity. As we plan, track, and complete more sprints, our measure of velocity becomes more accurate. Our team simply becomes more efficient over time as we accumulate a larger data sample of tracked time. It may take a few sprints to dial in the velocity of our team, but it will improve with each iteration.
Now what?
Now it’s time to get started planning a sprint and tracking your time. If you aren’t already using online tracking software, try our free trial of Intervals. The important thing is to start working towards your goal by doing something, anything, to collect data. It won’t be accurate at first, but it will get better. And before you know it, you will have recorded weeks and months of time tracking data. And your velocity will reveal itself.
Knowing our velocity is useful for several reasons. It gives us an idea of what to expect from our team under normal load. And it tells us how much time we might be able to spare for other projects. Most importantly, it’s useful for sprint planning. Each task, or story, we schedule into a sprint has an estimated number of time, or points, it will take to complete. Our velocity determines what we can and can’t fit into the sprint for it to be completed on time and under budget.
We’ll delve more into sprint planning in another post. Meanwhile, it’s time to find your velocity. Even if you aren’t practicing Agile Web development, understanding velocity will help any project manager make better planning decisions.
