Back To CourseAgile & Scrum Training
9 chapters | 131 lessons
As a member, you'll also get unlimited access to over 70,000 lessons in math, English, science, history, and more. Plus, get practice tests, quizzes, and personalized coaching to help you succeed.Free 5-day trial
Stephen has worked as a Project Manager and is PMP certified, as well as certified by the Scrum Alliance.
Randall's project team has recently started using Scrum, the most common form of Agile project methodology. As his team has become more familiar with Scrum, Randall introduces them to an important metric, known as velocity. The team is wary of metrics, because, in their experience, they are mainly used to increase demand and shorten deadlines under the claim of efficiency. Randall knows that his team can benefit from this metric if they understand how it's used. Before he can teach them this, he needs to define velocity for them.
Velocity is the measure of work completed by the development team within each sprint, which a repeated cycle typically spanning two to four weeks. The key in the definition of velocity is that it is the work completed by the development team. In Scrum, project work is broken down into user stories, which focus on specific functionality for an end user. The development team estimates the time and effort needed to develop and test each user story with points, or a numeric value. The work completed is the summation of these assigned points for user stories that have been fully developed and tested.
The other aspect to the definition of velocity is that the work is completed within a sprint. Sprints are used instead of weeks or days because it's within the sprint that the team commits to complete the user stories. When a team first begins Agile, they set the length of their sprints. While they can be as short as one week or as long as four weeks, it's important that the length stays consistent. Varying sprint lengths results in a varying amount of work completed. This would imply that the team's efficiency changes, but that might not actually be the case.
Once Randall has defined velocity for his team, he moves on to the calculation. There are two different versions of velocity that can be calculated, but the calculation is similar for each. The first version is actual velocity and involves dividing the total number of story points completed by the number of sprints. For example, if the development team has completed a total of 70 points over two sprints, the team's actual velocity would be 35 points per sprint. This is the more common version and the typical calculation for velocity.
The second version of velocity is expected velocity, which involves dividing the total number of estimated story points by the number of sprints. For example, if the development team estimates a total of 160 points over four sprints, the team's expected velocity would be 40 points per sprint. This version is less common and is mainly used in comparison with actual velocity to determine if the team is regularly meeting its commitments.
After the team understands what velocity is and how it's calculated, Randall is able to discuss with them how it can be used. He's hopeful that they will see the benefit of this metric. Velocity can be used within the development team, as well as outside of it, and each use of velocity provides a specific benefit for the development team. Velocity can be used for estimating, comparing, and measuring efficiency and growth.
Using velocity to make estimates works on two levels. The first is determining how much work a team can take on in the sprint. Although this is fairly straightforward, it is impactful to the team. If a team averages 30 points per sprint, the team should look to take on as close to 30 points as possible in any given sprint. This protects the team from mandates to take on more work in a sprint than they can complete. If additional work must be completed in the same time frame, measures should be taken to increase the team's capacity, such as adding developers and testers, or approving overtime pay for additional hours worked.
Another estimation that can be made based on velocity is setting a general timeframe within which a project may be completed. Individuals who are looking to make long-term plans can divide the total number of story points for the project by the team's velocity and determine about how many sprints the project should have. The key is that this timeframe is only an estimate and not a deadline to be used. Velocity should not be a constraint placed on the team determined by the amount of work remaining and the desired timeframe for its completion.
In addition to estimates, velocity can be used for comparisons to measure efficiency and growth. When making comparisons, the development team can only be compared to itself, not other development teams. Story point estimates are subjective and sprint lengths can vary. It would be incorrect to assume a team that averages 50 points per sprint is more productive than a team that averages 25 points per sprint. The teams might estimate the same user story as a 13 compared to a five, or one team has sprints of four weeks while the other has sprints of two weeks. The only consistent comparison is the same team against itself, specifically to verify that the team consistently matches or increases its velocity over time.
In Scrum, the primary metric is velocity, which measures the work completed by the development team within each sprint. Specifically, it takes the total number of points estimated for each user story and divides it by the number of sprints in which the user stories were completed. This calculation of velocity is also known as actual velocity. An alternative is expected velocity, which uses the total number of points estimated for work that should be completed instead of looking at the work actually completed. Velocity helps the development team determine how much work it can take on in a given sprint. It also allows individuals to make high-level estimates for how long a project will take. The development team can also use velocity to determine its efficiency and growth by following its velocity over time.
To unlock this lesson you must be a Study.com Member.
Create your account
Already a member? Log InBack
Did you know… We have over 160 college courses that prepare you to earn credit by exam that is accepted by over 1,500 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.
To learn more, visit our Earning Credit Page
Not sure what college you want to attend yet? Study.com has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.
Back To CourseAgile & Scrum Training
9 chapters | 131 lessons
Next LessonVelocity in Agile: Definition & Formula