It’s something you know. Those who rely on or offer Software-as-a-Service (SaaS) solutions are under constant pressure to innovate. Often, this means quickly building new features and releasing them more frequently.
Staying on budget and on time is also critical for staying competitive. Likewise, SaaS providers should also offer customers cost-effective solutions to their technology challenges. But that’s not all.
You must also always release quality code that provides seamless user experiences. So how do you maintain timeliness, cost-efficiency, and code quality in today’s sophisticated and complex engineering projects?
Enter engineering velocity.
Table Of Contents
What Is Velocity In Software Engineering?
In Agile software development, velocity is a metric that measures how many work units an agile team completes within a specific timeframe. That timeframe can be in hours, days, or weeks — but it’s often measured in two-week periods (sprints or iterations). Typical work units are engineering hours, story points, or user points.
It is vital to stick to the same sprint period and unit of work, from sprint to sprint. Calculating engineering velocity across multiple sprints and over long periods will be easier with this consistency.
Teams can often observe their velocity using previous timeframes of similar work to indicate how much they can accomplish in future sprints. Furthermore, it measures how fast the team achieves functional product increments. Here’s how it works:
How Does Velocity In Agile Work?
During the Agile software development process, velocity helps estimate the timeline an Agile team will need to complete a project. A completed unit of work here typically means that it is sufficiently functional to deliver value to the end-user, or with a project, it is potentially ready to ship.
Agile velocity works by having a team decide how many story points to assign to each unit of software work. For example, one point for fixing a bug or eight points for building an entire feature.
After this, the team assigns story points to all potential work units in the entire project. By adding up all story points, they can determine the total number of story points they need to build to complete the project (product backlog).
Teams then specify how many story points they will work on in a sprint (commitment). A team’s commitment is the number of deliverables it sets as a goal.
How Do You Measure Velocity?
Many engineers measure velocity by the average number of story points they achieve over three to five sprints.
Suppose a team completed three stories in a single sprint, and each story is worth four, five, and six points, respectively. This team’s total velocity would be 45 story points per sprint (3 X (4+5+6)).
If the team successfully replicated this over three sprints, its average velocity would be 45 story points per sprint (45+45+45) / 3 = 45 sprint velocity).
Now, here’s the deal.
When the team applies the three-sprint velocity to establish that the remaining work (backlog) has 450 story points, and it averages 45 story points per sprint, it means that team will take 10 more sprints to complete the entire project.
If each sprint lasts two weeks, the team can internally estimate that the project will take 20 weeks to complete (burndown velocity).
Credit: Burndown velocity by Sealights
Teams that are aware of velocity can plan realistic timelines to avoid overpromising on deliverables. But that’s not all.
- Each sprint is unique, so none of the three to five will have the same sprint velocity. That’s why teams often use the average sprint velocity to pinpoint a specific number as a guide.
- Any work not completed 100% by the end of the sprint does not count, even if it is 90% complete (commitment vs. completed work).
Credit: Workfront
- The team might plan to complete 50 stories per sprint but end up completing 42, 38, and 53, which requires it to recalculate its velocity, thus a new project delivery estimate. Here’s an example of how that fluctuates.
Credit: Sealights
- The team’s velocity has to be recalculated if one or more team members resign, move to another project, or if the team needs to fix new bugs from a previous sprint.
Should you measure average engineering velocity or a range?
Team members often use the average sprint velocity internally but use velocity as a range when communicating with clients.
The average sprint velocity is calculated as (42+38+53) / 3 = 44.33. If there are 450 story points left to complete, the project can be completed in approximately 10 sprints. Based on the average velocity of three previous sprints, the team estimates the length of time the project may take.
With ranges, teams communicate the best and worst-case scenarios to a client and C-Suite. So as an alternative to assuming every sprint will deliver 44.33 points, a team suggests it will deliver 38 to 54 story points per sprint to people outside the team.
Should velocity become a goal or an agile performance metric?
Software engineers should not rely on velocity as a performance metric. Unfortunately, many team leaders do. So, why not?
When a team is under pressure to maintain an average sprint velocity of 50, their focus can unconsciously shift from delivering quality iterations to delivering as many releases as possible. It might not test all lines of code thoroughly, fix all bugs, or prioritize optimization tasks with low story points.
It might make a thread of architectural decisions that focus primarily on delivering more story points than quality features. It is also common for teams to be oblivious to how their built functions might operate more cost-effectively when they are so focused on delivering more iterations at all costs.
It’s difficult to undo those architectural decisions over dozens of sprints. Yet, unoptimized features and poor code hygiene often lead to higher engineering costs than necessary.
Should you compare team velocities?
The fact that every team has its own engineering experience, turnover, tools, methodologies, and more variables makes it impractical to compare productivity or performance levels between teams using velocity.
The best way to judge the quality of a team’s work may be to look at the overall usefulness of the deliverables they deem complete.
Should you measure individual engineers’ velocity?
The measure of velocity in agile applies per team of engineers, not per individual engineer.
Should you aim to increase velocity in agile?
It can be misleading to focus on increasing velocity. A higher velocity does not always equate to higher productivity or shorter project timelines.
By completing multiple stories per sprint, a team earns more points. But if it cannot adhere to coding standards or fix issues early on, it risks releasing features that won’t function as expected. Remediation would take additional time, increasing the project’s timeline.
If velocity decreases, it might be a sign there are more bugs to fix or more tests to run — and that the team is addressing the issues. By identifying root causes earlier in development, the analysis can empower engineering to develop optimized, cost-effective solutions from the start (shift left).
If a team’s velocity increases, analyze why. The work should be of high quality, meaning that both the client’s expectations and the team’s technical requirements are met.
So, the focus should be on improving engineering velocity rather than increasing it. But how?
How Can Engineers Improve Velocity Without Increasing Costs?
The ideal situation is to achieve rapid product releases that deliver business value while sticking to your engineering budget. Here are five tips to help you improve engineering velocity without skyrocketing costs.
1. Prioritize and communicate engineering projects effectively
Rather than increasing product releases and story points, focus on delivering iterations that add actual value. Have your engineers conduct thorough testing and development to help achieve this. In addition, instead of measuring engineering performance or goals with sprint velocity, use:
- The cycle time for speed to value
- Iteration churn for predictability (a velocity chart with significant hills and valleys shows that a project is unpredictable, probably because it is complex and the requirements are changing rapidly.)
- Use Mean Time to Recover to measure build quality
Afterward, optimize sprint planning meetings to ensure that you clearly communicate these priorities to all stakeholders.
While Agile suggests not planning too far in advance, detailing what’s to be done in the next two to four sprints can help engineers build solutions that utilize relevant dependencies, skills, and tools from the very beginning, reducing rework.
2. Measure and share cost information with engineers to improve cost visibility
By empowering engineers with cost visibility, they can make informed engineering decisions that ensure profitability — and prevent overspending.
With the right cost intelligence platform, engineering teams can measure and track unit cost like cost per feature, per product, per sprint, per deployment, per team, or per project. By looking at the cost of several similar sprints, deployments, or projects, teams can then determine how much a sprint and subsequent sprints will cost.
CloudZero was designed for engineers. It’s easy to use and explore — and doesn’t require any training. Engineers can intuitively answer their own questions and understand their own cost impact. Our cost intelligence platform transforms costs into relevant dimensions — like dev teams, product features, and environments — then provides views, anomaly alerts, and more, just for the teams responsible for them.
This benchmark enables engineers to notice costs increasing or decreasing so they can identify cost drivers and prevent overspending — while also building cost-efficient software.
3. Treat cost as a first-class metric as well
The pressure to reduce release cycles and add new features often pushes teams to put costs on the back burner. Yet monitoring costs per deployment project, cost per development team, and cost per sprint can help identify areas where optimization might reduce unnecessary costs and improve code hygiene.
4. Use the 1:1:1 formula to balance team composition
Aim to have one senior, one regular, and one junior engineer for every three engineers on your team. If you have too many seniors, you might end up developing complex solutions to simple problems or not get any work done at all as they struggle to agree on whose approach is the best.
With mostly regulars, your project could be bland, lacking in a senior’s touch or a junior’s imagination. A team with too many juniors may not have the skill set necessary to solve more complex issues on time or at all.
5. Provide engineers with the cost insights they need to improve velocity
Engineers aim to improve code and user experiences. Since they aren’t involved in cost allocations and budgeting, they sometimes make architectural decisions without considering cost implications.
With access to cost data for individual teams, features, development projects, and deployments, engineers can more easily determine the impact of their decisions on the organization’s finances.
They can then brainstorm and implement more cost-effective solutions. As they continuously develop better processes for designing solutions, velocity will inevitably improve.
Avoid Cost Overruns Without Compromising Engineering Speed With CloudZero
CloudZero empowers engineers to monitor the cost impact of every technical decision they make during the development process — enabling them to identify engineering activities that are driving costs.
Engineering teams can drill into cost data from a high-level down to the individual components that drive their cloud spend — and see exactly what AWS services cost them the most and why.
With detailed cloud cost intelligence, teams can make informed decisions to reduce spend or rearchitect infrastructure for profitability.
CloudZero also offers insights into specific cost dimensions that matter, such as cost per deployment, cost per feature, and cost per dev team, unlike traditional cost management tools.
to see how CloudZero can help you improve engineering velocity without sacrificing cost-efficiency.
The Modern Guide To Managing Cloud Costs
Traditional cost management is broken. Here's how to fix it.
