Best Practices to Improve Product and Feature Velocity

Feature velocity is one of the product management buzzwords but what exactly does it mean?

This is one of the questions we answer in the article, so if you’re after the answer, you’re in the right place.

We also discuss why velocity matters, and look at ways to improve your team’s velocity.

Are you ready to jump in?

TL;DR

• Velocity is a metric that describes how much work a team can deliver during a sprint.
• Feature velocity is how quickly they are able to add new features to the product.
• Tracking feature velocity allows teams to estimate accurately how long work will take to complete. This helps reduce risk and set expectations accurately.
• Variations from the usual velocity could be an indication of inefficient processes, technical debt, or substandard quality.
• Each team calculates its velocity in a unique way which means. Consequently, it’s not a good metric to compare the productivity of various teams.
• Product features are its characteristics. They describe its functionality and appearance.
• Benefits are the positive outcomes features bring to users.
• A product roadmap consists of themes; themes consist of initiatives and initiatives of epics.
• It’s impossible to complete an epic in one sprint, so we break them down into user stories.
• A user story contains information about how the feature works and its benefits for the user.
• Agile teams use story points to express velocity and burndown charts to track it.
• To improve feature velocity, you need to understand how much of the total team velocity goes into dealing with defects and technical debt.
• Increasing velocity requires aligning development and engineering teams to enable not only feature development but also continuous integration.
• Identifying and delivering minimum viable features is another way to increase velocity. That’s because you only build what customers need.
• Developing only the features that are in line with product vision also increases velocity.
• Regular backlog grooming and demo meetings give the team a chance to clarify what to build. As a result, they can get it right the first time (RFT).
• Shorter iterations and breaking down features into smaller ones reduce the time needed to ship.
• Feature flags allow you to enable or disable a feature without modifying or redeploying the source code. This increases the velocity.
• Along with feature velocity, also track adoption to make sure you’re bringing positive change to user experience.
• Want to see how Userpilot can help you boost your team’s feature velocity? Book the demo!

What does velocity mean in product management?

Velocity is a metric that describes how quickly a development team delivers during its iterations. It is a well-known instrument used in Agile delivery frameworks like Scrum.

Velocity is expressed in story points completed during each delivery cycle and calculated at its end.

What is feature velocity?

Feature velocity is the speed at which the team is able to deliver the planned features.

To calculate feature velocity, you need to deduct the effort needed to deal with defects and technical debt from the total velocity.

Why should development teams measure velocity?

Velocity is a valuable metric that enables product managers, product owners, and scrum masters to estimate how quickly the team can work through the backlog items.

The more accurate the estimates, the lower the risk and the more realistic the expectations of the stakeholders.

To improve the accuracy of the estimates, it’s a good practice to use the average velocity from the last three sprints.

That’s because velocity is not a constant.

For example, it’s normal for the velocity of your team to be low in the early days of their work together. However, as your team gets more efficient by streamlining its processes, the velocity will grow.

While small fluctuations in velocity are normal, large variations can be indications of issues.

For instance, a drop in velocity may mean that some of the Agile team’s processes are not efficient enough and technical debt is creeping in.

On the other hand, a dramatic increase in velocity might indicate the complexity of the tasks wasn’t properly assessed. Corner cutting is another common cause.

That’s why measuring and tracking a team’s velocity is critical.

However, velocity is not good for comparing the efficiency of different teams. The value of story points and velocity is relative and unique to individual teams.

What are product features?

Product features are the characteristics of the product.

They describe either what the product has, like a resource center, what it does, like triggering in-app messages, or what it looks like.

In the context of feature velocity, features are the backlog items and they represent the work that needs to be done to deliver the planned product functionality.

Product features vs benefits

If product features are the functionality of the product, benefits are what the users gain from using them.

While many companies still believe it, product success is not measured by the number of features you ship. Instead, it’s the positive impact that the product has on users’ lives that matters. In other words, you want to deliver benefits, not features.

For this reason, you should only use feature velocity to track how effective teams are at working through their backlogs. It doesn’t show how successful the product is.

Having said that, low velocity limits the teams’ ability to deliver the features and so indirectly, it has an impact on your success chances.

Planning new features: Epics and User Stories

Ultimately, product success depends on what the product manager or product owner puts in the backlog and how they organize it.

What are agile epics?

In agile, epics are large chunks of work that a team can’t complete in a single sprint. They are bigger than user stories but smaller than initiatives.

What are initiatives?

They are higher-level projects that you need to achieve the product goals, called themes. Each of the goals may require a number of initiatives, and each initiative may serve a number of goals.

What are user stories?

User stories are the smallest chunks of work in Agile and are basically descriptions of product features.

They are written from a user’s perspective and describe what the user can accomplish thanks to the feature and its benefits.

This allows developers to focus not only on what the feature does but also on the purpose it serves.

User stories follow a simple template:

As a < User Persona >, I want < feature > so that < JTBD/benefit >

As a product manager, I want a heatmap so that I can easily identify the most popular features on each page.

Where do features fit in here?

Features and user stories are pretty much synonymous.

However, this very much depends on their interpretation by different organizations. In some, a feature may fall somewhere between an epic and a user story.

The confusion partly results from the fact that some Agile frameworks like Scrum don’t use either of the terms and instead prefer backlog items.

Apart from features, the backlog can have also defects and technical debt and they are also assigned story points.

How to track feature velocity?

Let’s imagine that your team has worked together through a few sprints and they have averaged 19 story points per sprint.

If your features are worth 200 story points, your team will need at least 11 sprints to complete the work.

It doesn’t mean, however, that they will complete 19 points in each sprint. Unexpected barriers and technical debt may cause a drop in feature velocity, while improved processes can increase it.

Scrum, and other Agile frameworks, use empirical evidence to adjust their estimates. So after completing each iteration, the scrum master re-calculates the average velocity for the team and uses the new value for future estimates.

To track progress, Agile teams use burndown charts. They show both the total work that needs to be done and the work that’s already completed.

Best practices to increase the velocity of new feature releases

Now that we understand what feature velocity is and how it’s tracked, let’s look at some good practices that can help you increase the velocity.

Understand where team effort is being spent

Before you start making any changes to increase feature velocity, make sure you understand what they spend most of their energy and time on.

As mentioned, your team’s backlog may include not only new features but also defects and items needed to either deal with or prevent technical debt.

While your team’s overall velocity may be solid, ultimately, you’re interested in feature velocity, because that’s what you need to launch your MVP or roll out an update.

Align engineering teams with development teams

To be able to ramp up your velocity, you need to address the issue of technical and design debt. That’s because achieving high feature velocity is dependent on your ability to integrate the new features without delays.

In other words, you need to make sure your product infrastructure needs to be robust enough to support the new features. Otherwise, are going to put it under excessive stress which will slow down the overall velocity of your team.

To make it happen, the work of your engineering team needs to be closely aligned with the work of the development teams.

Use minimum viable features

Feature velocity very much depends on building the right functionality and not wasting your time on unnecessary things.

So before you commit to building a feature, ensure this is what your customers need.

Invest your time in product and customer discovery to uncover user pain points, needs, and desires.

Next, search for ideas to address the needs and use experimentation to validate them.

When you are onto something, don’t try to deliver the perfect product or feature. Instead, focus on building minimum viable features. Then launch them and collect user data on how to improve and develop them in future iterations.

Prioritize features based on your product vision

The fact that your users have certain needs, no matter how legitimate they are, doesn’t mean you need to solve them.

When in doubt about what features you should prioritize, refer back to the product vision, and choose only the opportunities that are in line with your organizational and product goals.

Regular backlog grooming and story iterations are a must

To increase your team’s velocity, you need to give them the information and the resources they need to get things right the first time.

Back in the day when waterfall software development was the way to do things, a lot of effort was wasted building products based on detailed requirements just to find out in the end that this wasn’t what the customer meant.

Regular backlog grooming sessions, short iterations, and increment demos, which are typical of Agile development, allow teams to clarify they are working on exactly what the customer needs.

This eliminates the need for expensive and time-consuming rework.

Break larger features into smaller ones to increase velocity

Another way to help your teams increase velocity is by breaking down large features into smaller ones.

Smaller chunks of code are easier and quicker to both develop and integrate.

It also means your customers get increased functionality at the end of every iteration. And as they start using them, you can collect usage data and feedback and use it to inform future sprints.

Finally, it’s also easier for sprint teams to estimate the story points for smaller features and fit them into a sprint.

Use feature flags to increase feature velocity

Feature flags, aka feature toggles, allow you to switch on or off a feature without the need to modify or redeploy the source code.

This means you can deploy new features yet make them invisible to users until you enable them. And when you do so, you can only choose one user segment that will have access.

What are the benefits of using feature flags? You should use them to:

• test new features and ensure their stability before releasing them to all users
• switch off individual faulty features without rolling back the whole release
• deploy and integrate features continuously and only enable them when ready
• avoid merge problems and debug issues

Track feature adoption along with feature velocity

Adding new features to your product will always have an impact on user experience.

We all hope that the impact is positive, but don’t take it for granted. For example, adding a lot of new functionality may affect product usability and make the UI overwhelming.

That’s why, apart from velocity, you should also track feature adoption. You can easily do it by tracking product usage after every feature release with tools like Userpilot.

Conclusion

Feature velocity is not a measure of how successful your product is. However, it is one of the critical factors that have an impact on your product growth and its long-term success.

That’s why it’s essential you commit time and resources to increase your velocity even if it means slowing down the releases of new features initially.

If you’d like to see how Userpilot can help you track new feature adoption and collect user feedback to inform future iterations, book the demo!