{"id":2424,"date":"2021-12-09T06:18:44","date_gmt":"2021-12-09T06:18:44","guid":{"rendered":"https:\/\/www.teamly.com\/blog\/?p=2424"},"modified":"2022-01-10T07:16:54","modified_gmt":"2022-01-10T07:16:54","slug":"how-to-improve-team-velocity-in-agile","status":"publish","type":"post","link":"https:\/\/www.teamly.com\/blog\/how-to-improve-team-velocity-in-agile\/","title":{"rendered":"4 Steps Towards Improving Team Velocity in Agile"},"content":{"rendered":"

Team velocity is a metric that upper management and CEOs often want to increase\u2014and that\u2019s totally understandable. Why wouldn\u2019t you want a more productive and efficient team of professionals?<\/p>\n

Unfortunately, there\u2019s 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\u2019s output increases in quality within sprints.<\/p>\n

An important part of a project manager\u2019s growth is learning to improve velocity without harming the team\u2019s morale<\/a> and the quality of its work\u2014and this is precisely what we\u2019ll discuss in this blog post.<\/p>\n

Let\u2019s dive right in, shall we?<\/p>\n

\"What<\/p>\n

<\/span>What is sprint velocity?<\/span><\/h2>\n

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\u2019re measured in engineer hours, story points, tasks, ideal days, but there are many other options organizations can choose from.<\/p>\n

Same applies to time frames. Teams can choose to organize their work in sprints, weeks, iterations, etc. It\u2019s important to underline that consistency is key in this case. Once you\u2019ve established your preferred measurement units, it\u2019s essential to keep using them if you\u2019re looking to reliably calculate your team\u2019s velocity.<\/p>\n

However, velocity isn\u2019t exclusively used as a lagging indicator\u2014it 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.<\/p>\n

It\u2019s worth mentioning that, like with most estimations, they become more reliable as you gather more data.<\/p>\n

\"Improving<\/p>\n

<\/span>Improving sprint velocity<\/span><\/h2>\n

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\u2019s essential to keep in mind that while quantifying human effort is helpful, there\u2019s a significant element of imprecision involved. Therefore, it\u2019s always a good idea to tweak and adapt these approaches to suit the organization, teams, or individuals you work with.<\/p>\n

<\/span>1. Zoom out<\/span><\/h2>\n

As we mentioned above, velocity is an excellent tool for estimating the productivity of a group of people, yet it shouldn\u2019t 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.<\/p>\n

It\u2019s 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.<\/p>\n

It\u2019s 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\u2019 opinions into account may seriously damage team morale and productivity<\/a>, which is exactly the opposite of what you want.<\/p>\n

<\/span>2. Don\u2019t switch the context<\/span><\/h2>\n

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.<\/p>\n

Think of it this way\u2014a 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\u2019s 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\u2019t just unproductive; it\u2019s simply harmful to a person\u2019s wellbeing and productivity\u2014and there\u2019s plenty of research to back that up.<\/p>\n

Researchers at the University of Sussex published a study<\/a> back in 2014 called \u201cHigher media multitasking activity is associated with smaller gray-matter density in the anterior cingulate cortex.\u201d 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.<\/p>\n

But there\u2019s 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.<\/p>\n

\"Strategize<\/p>\n

<\/span>3. Strategize testing<\/span><\/h2>\n

Testing can get messy\u2014and 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.<\/p>\n

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.<\/p>\n

Similarly, it\u2019s important to eliminate the testing that isn\u2019t really needed\u2014and there\u2019s plenty to choose from here. The most obvious category is, of course, the code that hasn\u2019t 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\u2019s backlog will give it a considerable boost in productivity.<\/p>\n

Another way to increase your team\u2019s output is to go without testing the products\u2019 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, \u201cis the time investment worth the benefit that it will yield?\u201d.<\/p>\n

\"Embrace<\/p>\n

<\/span>4. Embrace cross-training<\/span><\/h2>\n

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

If you\u2019re 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.<\/p>\n

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\u2019s collective skill set.<\/p>\n

However, the benefits of cross-training don\u2019t end there. Here are a few more reasons you should consider it:<\/p>\n