4 Steps Towards Improving Team Velocity in Agile

4 Steps Towards Improving Team Velocity in Agile

Team velocity is a metric that upper management and CEOs often want to increase—and that’s totally understandable. Why wouldn’t you want a more productive and efficient team of professionals?

Unfortunately, there’s a massive difference between increasing and improving sprint velocity. The former predominantly focuses on growing the amount of work that is executed within a sprint, often at the expense of the quality of the work produced. The latter, on the other hand, revolves around ensuring that a team’s output increases in quality within sprints.

An important part of a project manager’s growth is learning to improve velocity without harming the team’s morale and the quality of its work—and this is precisely what we’ll discuss in this blog post.

Let’s dive right in, shall we?

What is sprint velocity?

In agile, velocity is a term that reflects the amount of work a team delivers within a particular time frame. There are multiple ways to express these amounts. Typically, they’re measured in engineer hours, story points, tasks, ideal days, but there are many other options organizations can choose from.

Same applies to time frames. Teams can choose to organize their work in sprints, weeks, iterations, etc. It’s important to underline that consistency is key in this case. Once you’ve established your preferred measurement units, it’s essential to keep using them if you’re looking to reliably calculate your team’s velocity.

However, velocity isn’t exclusively used as a lagging indicator—it also works as a metric that helps teams plan and strategize their work going forward. If, for instance, a group has been continuously delivering a certain number of story points in a sprint, this allows them to confidently estimate the amount of work they will be able to execute in the future. As a result, this allows you to calculate the number of sprints it will take to execute an entire project.

It’s worth mentioning that, like with most estimations, they become more reliable as you gather more data.

Improving sprint velocity

A scrum master, team leader, or CEO can do a variety of things to significantly boost the output of one or more teams. However, it’s essential to keep in mind that while quantifying human effort is helpful, there’s a significant element of imprecision involved. Therefore, it’s always a good idea to tweak and adapt these approaches to suit the organization, teams, or individuals you work with.

1. Zoom out

As we mentioned above, velocity is an excellent tool for estimating the productivity of a group of people, yet it shouldn’t be confused with objective truth. By crunching data and boiling complex events down to bare numbers, we simplify things considerably. This is why comparing velocities across teams may not yield solid results and may prevent you from setting realistic expectations. The same principle applies to comparing velocity between projects.

It’s critical to use metrics like velocity responsibly. Instead of using it on its own, always consider the bigger picture. Even better, use in combination with other relevant metrics to eliminate tunnel vision.

It’s also critical to receive feedback from your team in regards to the metrics you use and the quality of your estimations. Failing to take your colleagues’ opinions into account may seriously damage team morale and productivity, which is exactly the opposite of what you want.

2. Don’t switch the context

One way to improve team velocity is to make sure that the tasks that a team is working on fit a single context. Moreover, it can even be argued that context-switching is simply incompatible with agile.

Think of it this way—a group of people provides their undivided attention to executing a set of tasks in a very tight time frame. Often, tasks are grouped based on a common narrative, whether it’s task type, feature, stage in the development process, and so forth. This structure is what allows the team to function in an efficient manner. Disrupting this context by introducing a task from previous contexts that are unrelated to your current spring is essentially a form of multitasking that isn’t just unproductive; it’s simply harmful to a person’s wellbeing and productivity—and there’s plenty of research to back that up.

Researchers at the University of Sussex published a study back in 2014 called “Higher media multitasking activity is associated with smaller gray-matter density in the anterior cingulate cortex.” The paper indicates that people who tend to multitask on a regular basis have decreased brain density in the anterior cingulate cortex, which controls things like compassion and emotional control.

But there’s more! Other studies suggest that aside from slowing you down and damaging your brain, multitasking can have a significant effect on your IQ. Research published by researchers at the University of London found subjects who alternated between tasks have experienced a decline in IQ of about 15 points, which is obviously undesirable if your job revolves around complex topics.

3. Strategize testing

Testing can get messy—and a lot of structure is lost in the process. A very common issue that teams have to deal with is overlapping tests, which end up wasting a lot of valuable time for both developers and QA engineers.

A good way of structuring things is to assess your UI and integration test schedules and go the extra step with planning them out since these are the areas where many overlapping tests occur.

Similarly, it’s important to eliminate the testing that isn’t really needed—and there’s plenty to choose from here. The most obvious category is, of course, the code that hasn’t been changed since the last time it was tested. While this does sound like an obvious mistake, it happens quite often in companies of all sizes. Eliminating these pointless tasks from your team’s backlog will give it a considerable boost in productivity.

Another way to increase your team’s output is to go without testing the products’ features that are very rarely used. While quality assurance is a vital component in developing a useful and satisfying product, we should also strive to be pragmatic in our approach by asking ourselves, “is the time investment worth the benefit that it will yield?”.

4. Embrace cross-training

Cross-training is an efficient way to eliminate bottlenecks and potential gaps in a team’s collective expertise. It’s also a really useful practice when one person is away for a longer period, allowing their colleagues to effortlessly cover their responsibilities.

If you’re going to be involved in a longer project, it would also make sense to look into restructuring the team in terms of job titles. Eliminating individual roles could be a good solution to low accountability and siloed communication.

If your budget allows it, consider running training sessions with your team or even hiring third-party specialists to consult them, thus growing your team’s collective skill set.

However, the benefits of cross-training don’t end there. Here are a few more reasons you should consider it:

• Increased self-awareness regarding team members’ roles and purpose.
• Increased employee development and professional growth opportunities.
• More opportunities to provide better support and services.
• An employee base that can confidently switch between roles within the organization.
• A broader range of criteria for management to evaluate employees for their contributions and challenges.

Well, that’s fine and dandy, but just mentioning the ways the organization will benefit from cross-training is unlikely to actually engage them in doing so. Businesses should consider incentive programs that will help motivate employees to share their trade secrets with their colleagues.

Similarly, it’s worth taking into account that by cross-training personnel, you’re pretty much implying that they might have to take on additional responsibilities. Therefore, it’s essential to create the right conditions and incentives for such endeavors to work.