Agile methodologies support both strategic and tactical schedules and time management. Velocity, the measure of a development team's work speed, is a key factor in time management for any project.
You determine velocity by the number of user story points the development team completes in each sprint. At the end of each sprint, the scrum team looks at the requirements it finished and adds up the number of associated story points. The total number of completed story points is the scrum team's velocity for that sprint. After the first few sprints, you start to see a trend and can calculate average velocity, which is the total number of story points completed divided by the total number of sprints completed.
Using velocity to estimate the timeline on an agile project
After you run a sprint and know the scrum team's velocity, you can forecast the remaining time on your project:
Add up the number of story points for the remaining requirements in the product backlog.
Determine the number of sprints you need by dividing the number of story points remaining in the product backlog by the velocity.
If your product backlog contains 800 story points and your development team velocity averages 20 story points per sprint, 800/20 = 40 more sprints.
Determine how much time it will take to complete the story points in the product backlog by multiplying sprint length by the number of remaining sprints.
If you need 40 more sprints to finish the project and each sprint lasts two weeks, your project will last 80 more weeks.
In the beginning of a project, velocity varies considerably from sprint to sprint. When the project is new, the scrum team typically has a low velocity. As the project progresses, velocity should increase and become more consistent as the scrum team learns more about the product and matures as a team. Setbacks within specific sprints can decrease velocity from time to time, but agile processes like the sprint retrospective can help ensure those setbacks are temporary.
When you know the scrum team velocity and the number of story points for the requirements, you can use the velocity to determine how long any given group of requirements will take to create.
Use velocity to measure development speed after a sprint, rather than to dictate how much work a scrum team should complete before a sprint. If velocity turns into a target, rather than a past measurement, scrum teams may be tempted to exaggerate estimated story points in order to meet that target, rendering velocity meaningless.
How to increase velocity on an agile project
Scrum teams can increase their velocity throughout agile projects, making projects shorter and less costly. Increasing velocity can save a good deal of time and, consequently, money. Everyone on a scrum team can help get higher velocity with every successive sprint:
Remove project impediments or roadblocks: Anything that keeps a development team member from working to full capacity decreases velocity.
Avoid project roadblocks: Find out about the processes and the specific needs of groups your team will work with so that you can head off roadblocks before they arise.
Eliminate distractions: The scrum master’s job is to protect the development team from distractions. By making sure people don't request non-sprint, goal-related work from the development team — even short-term tasks — the scrum master can keep the development team focused on the sprint.
Solicit input from the team: Everyone on the scrum team can provide ideas for increasing velocity in the sprint retrospective meeting. The development team knows its work the best, and may have ideas on how to improve output. The product owner may have insights into the requirements that can help the development team work faster. The scrum master has seen any repetitive roadblocks and can discuss how to prevent them.
