Increasing Your Scrum Team's Velocity
How much attention do you give to your team’s velocity? If the answer is very little or none, it is time to change that. Velocity is an important metric to track in the Agile and Scrum space. It allows the development team to have insight into how effective and efficiently they operate. It also shows stakeholders, how a team is progressing from one Sprint to the next. There are many tricks, but only a few mechanisms which prove to drive improvements in velocity over time.
Defining Velocity
Velocity is the measure of how much work a team can complete within just one Sprint. The velocity is a summation of how many User Story points the team expects to achieve, in that set period. If the Sprint is two-weeks, and the team usually completes 100 User Story points over those two weeks, 100 is the team’s velocity.
The more the team’s velocity increases, the more capacity the team has to take on more work. As they increase velocity, they increase their ability to conquer more User Stories in each Sprint and complete more work. Velocity gets a calculation at the end of each Sprint. Once a development team goes through a significant number of Sprints, the average over those Sprints becomes a velocity which can accurately predict what the team will complete.
Avoid Context Switching and Manage Resources
Keep their focus on one task at a time, driving it to completion. Within Agile, you want to avoid context switching as much as possible. Context switching occurs when an individual has to switch topics, i.e. what they are working on. The time it takes them to put one piece of work to a close and pick up a new, takes away resources, time. It also drives down the velocity of a team. Protect your team from context switching to increase velocity over time. Be aware that muti-tasking is a myth. Human beings cannot multi-task - only switch contexts.
Resource stability is also crucial for development teams as they move from one Sprint to the next. If a development team of five people loses one individual, what happens to their velocity? It is indeed not going to increase, and likely will not remain stable either. If a new team member comes on, he or she does not increase the velocity to the same level the prior team member did. Manage resources and try to be consistent in keeping teams together. Sometimes, it is inevitable to replace team members (someone leaves, is off sick, etc.) but in these cases, allow some switching time cost into planning the sprint.
Teach Everyone, Everything
As the Scrummaster, it is your job to have team members constantly cross-training each other. This will prevent bottlenecks and issues if someone is sick or leaves the company. If you have just one person who knows how to code or refresh a database, and that individual leaves, the team is going to be in a tight spot. To increase velocity, cross-train and use knowledge transfer sessions to get everyone at the same level. To encourage cross-training, discourage the use of job titles such as “QA tester” or “java developer”. In Scrum, everyone is a team member.
It is essential to observe the team’s velocity and calibrate to improve it over time. Throughout a project, (after the initial few sprints) team velocity may be constant or even dip. To increase velocity, try the following:
Use cross-training and ensure knowledge transfer is consistent
Avoid context switching. Keep each team member to one task at a time
Be aware of resource management and maintaining a constant development team
Use a rolling average of the last 3-4 sprints to plan the next sprint. Remove any anomalous outliers to obtain a better average.
Do not compare velocity across different teams. Each team organically develops their own velocity.
Use consistent definition of done across your sprints
Recognize that high velocity doesn’t necessarily mean having a high level of success or quality (i.e. are we building the right stuff?). It simply reflects the rate at which the team is completing work (i.e. building the work right).