Software Development Velocity
A Comprehensive Guide to Measuring and Improving Team Performance
Software development velocity is an important metric in today's tech world. Engineering managers use this measure to estimate team progress and project timelines.
While not recommended, some companies use velocity metrics for individual performance improvement plans and development plans.
Based on my experience at Microsoft and Salesforce, tracking velocity at both individual and team levels helps keep goals on track. Senior engineers and managers should identify gaps in processes, tools, and resources to improve the team's velocity.
In today’s article we will discuss about,
Basic definition of Software development velocity
Factors that affect velocity
Benefits
Considerations
My experiences regarding velocity with companies.
What is Software Development Velocity?
General Definition:
Software Development Velocity measures how much work a development team/individual can complete in a given time period, typically measured in "sprints" (usually 1-2 weeks). It's not about raw speed, but rather about predictable, sustainable delivery of value.
Measurement Units:
User Story points: Abstract units that combine complexity, effort, and risk
Completed user stories or features
Working software delivered
Factors that affect Software Development Velocity
Software Development Velocity depends on many factors in a day to day life of a Software Engineer. Few important factors are as below,
An Individual Contributor’s Development Velocity
Lack of prioritization
Unclear feature clarity
Lack of feature/user story readiness (Pre-requisites)
Insufficient mentorship from experienced peers in the team
Implementation without proper well thought design with all possible options, limitations and hurdles.Â
Team’s Development Velocity
Unclear product vision
Team size and experience
Technical debt
Development infrastructure
Team collaboration/helping culture encouragement from managers
Building too many features at once
Spending too much time on complex infrastructure instead of customer centric features
It is important to understand the velocity definition from the manager/leadership of your company as every company has different core values and different definition of development velocity.
Benefits of measuring development velocity
Helps in sprint planning and estimations
Provides insights into team capacity
Enables more accurate project timelines
Identifies bottlenecks and areas for improvement
Important Considerations
Velocity varies between teams (shouldn't be used for comparison)
Should be measured over time to establish patterns
Quality shouldn't be sacrificed for speed. When in doubt, always clarify this with your manager about expectations
Not a measure of individual performance unless it’s performance improvement plan scenario
Everyone in the team should try to improve upon processes, tooling, collaboration to increase the velocity
Experiences
Deployment process hindering team velocity
At Microsoft and Salesforce, we initially faced challenges with manual code deployment. Our team spent excessive time building and deploying code to production, relying heavily on tribal knowledge. This significantly slowed our software development velocity.
Given the advancements in CI/CD technology, I proposed automating our pipelines. This automation would allow engineers to focus on design and implementation work.
In new system, when code merges into the repository, it triggers an automated CI build pipeline then CI pipeline generates deployment artifacts. Once artifacts are ready, the CD pipeline automatically deploys to all environments in a staggered manner
Learning:
Automate processes in Software Engineering lifecycle wherever it’s possible. This will increase your team’s velocity.
Maintenance work hindering team velocity
In my customer-facing product team, we handle various maintenance tasks including Technical debt, Vulnerability fixes, Availability monitoring, Customer issue investigations
These operational tasks require continuous attention from our team. Previously, everyone would work on these daily maintenance tasks on demand, which reduced our team's velocity on other deliverables.
To solve this, we implemented a weekly rotation policy. Each week, one team member handles the maintenance work while others focus on feature development. This approach helps maintain our team's overall productivity.
Learning:
Every manager should try to organize innovative process structure to approach different kind of work for the team, so that mainstream development velocity doesn’t get affected by all the non-important maintenance and operational works.
Support My Content
» SHARE, SUBSCRIBE
» REFER to a FRIEND