How Do I Increase the Velocity of My Scrum Team?
As your team gains experience with agile, they should get better at it.
Some processes will run smoother, some questions no longer need to be asked. The obvious result is that more “product” will be output during each sprint as time goes on.
But what happens when your team plateaus too early… or never seems to climb at all?
Identify Your Team’s Capacity
The first thing you need is a realistic expectation of how many hours per week each individual will be allocating to this project. Multiply this number by the number of weeks your production sprint is scheduled to last (typically two weeks). From this number, subtract all the “ceremony” time such as sprint planning, standups, retrospective, etc.
The number you’re left with is the time each individual will have to work on sprint tasks.
Take a look at the number for each team member. Do they have enough time left to put their head down and drive sprint items to “done?” One common problem with underperforming Scrum teams is they don’t have enough time to focus. Team members should be dedicated to only one Scrum team if at all possible, particularly for those who are doing the majority of the “heads down” work. For a software team, this is typically the software developers.
Some other team members can often work on more than one team, for example a ScrumMaster can often work effectively with up to two Scrum teams. If you have developers split across four projects, however, it’s unlikely you’ll see the type of results you want. Narrow their focus and I expect you’ll see throughput dramatically increase.
Calculate Your Team’s Velocity
It’s difficult to know whether your Scrum team is improving their throughput if you aren’t measuring velocity. A simple way to measure how much a Scrum team is able to produce is through velocity, typically expressed as story points per sprint.
The first step is to have the development team estimate the number of story points, then start measuring how many story points the team drives to “done” each sprint, and track it over time.
For a thorough walkthrough of how to estimate user stories to create a velocity, see my Step-by-Step Guide for Estimating Software Development blog post.
Your team’s velocity should follow a cycle of increases early on until there is a fairly consistent pace of progress.
Find Bottlenecks and Underutilizations
One way to increase velocity is to find which processes or tasks are holding things up. If you can identify those bottlenecks before they happen, you can create a plan that keeps everyone fully engaged most of the time. If some of your bottlenecks are created by lack of adequate response from the organization, you can learn some ways to deal with that .
Find Wasted Time and Inefficiencies
Are there processes being followed that are unnecessary or not performed to expectation? For example, if daily standup meetings take ten minutes of “chitchat” before getting started, that’s ten minutes wasted of your capacity for every member involved every day. If you have a typical seven-person team, that’s over an hour of time wasted every day. Start your Scrum ceremonies on time, and stay focused, particularly when the entire Scrum team is in the room.
Find the Right Mix of Resources
If certain skills are in high demand and causing bottlenecks, you can allocate external resources for the team. This can be done on a temporary or permanent basis.
You also need the right mix of senior and junior personnel on the team. With all junior and no senior members, you’ll have a tough time generating throughput. Another bottleneck can occur when you have several very junior members on a team, and all your senior members spend most of their time helping them.
Follow the Rules
Velocity can suffer when you don’t follow the rules. Eliminating standup meetings might sound good for productivity, but there’s a cost involved. Those meetings serve an important purpose, keeping everyone informed and eliminating other unnecessary meetings. Not time-boxing your standups to 15 minutes can cause velocity problems by spending too much time. And here are a few more important rules that impact velocity:
- Only the development team should decide how much to commit to for each sprint, not the product owner
- Every sprint has a fixed duration and a “pencils down” time
- Sprints should always result in a “shippable” state of the product
- Sprint reviews and retrospectives must be held. Read more about how Scrum ceremonies can help you meet your business goals.
Review the Process
Speaking of retrospectives, this is another element that “creative” managers sometimes seek to eliminate. But, like the morning standups, sprint retrospectives serve an important purpose. Not only do they close the cycle of one sprint and give way to another, but they also offer an ideal point to capture what went right and what went wrong, and how the team can adjust the process to improve results. This creates an ever evolving learning process – one that is absolutely crucial toward improving your velocity over time.
Offer More Training
More training can help increase your team’s velocity as well. Not so much with technical skills, although that may provide a boost in some cases. What I’ve found most effective for many agile teams is Scrum coaching to improve their understanding and adherence to the right processes. This also reduces the “unconscious” resistance that might grow within struggling teams.
Other potential training opportunities would be in communication, teamwork, and conflict management. Any or all of these could help reduce time spent resolving issues and improve the team’s decision-making skills.