How to Discuss Engineering Velocity in English

Engineering velocity is one of the most frequently discussed — and most frequently misunderstood — concepts in software teams. It refers broadly to how quickly a team can deliver valuable software, but it encompasses many nuances. Knowing how to discuss velocity clearly and honestly in English will help you contribute more effectively to planning meetings, retrospectives, and conversations with engineering leadership.

Key Vocabulary

Throughput Throughput is the number of work items a team completes in a given time period. It is a direct measure of output, often tracked as the number of stories, features, or pull requests merged per sprint or per week. Example: “Our throughput has been consistent at around 12 story points per sprint over the past two months.”

Cycle time Cycle time measures how long it takes for a single piece of work to move from the moment work begins until it is delivered. Shorter cycle times indicate a leaner, more efficient workflow. Example: “Our average cycle time has dropped from six days to two days since we started doing smaller pull requests.”

Lead time Lead time is the total elapsed time from when a request is made (such as when a ticket is created) until the work is delivered. It includes any time the work spends waiting in the queue before being picked up. Example: “Our lead time is much longer than our cycle time, which tells us that tickets are sitting in the backlog for a long time before we start working on them.”

Technical debt Technical debt is the accumulated cost of shortcuts, outdated code, and poor design decisions that slow down future development. Teams with high technical debt often have lower velocity because changes require more careful handling. Example: “A significant part of our velocity loss this quarter is attributable to the technical debt in the authentication module — every change there takes twice as long as it should.”

Capacity Capacity is the total amount of work a team can realistically accomplish in a sprint or iteration, accounting for holidays, meetings, on-call duties, and other obligations that reduce available development time. Example: “We only have 60% capacity this sprint because two team members are at a conference and one is on leave.”

Common Scenarios Where This Language Is Used

In a sprint planning meeting: “Based on our average throughput over the past four sprints, I’d estimate we can take on eight to ten story points this sprint. We have slightly reduced capacity due to the public holiday on Monday.”

In a retrospective: “Our velocity dropped significantly this sprint. Looking at the data, I think the main contributing factors were the production incident on Wednesday and the large pull request that was blocked in review for three days.”

When reporting to leadership: “Over the last quarter, our team’s average throughput was 40 story points per month. We expect this to improve in Q3 as we pay down some of the technical debt in the data pipeline.”

When discussing priorities: “If we want to increase velocity, we have two options: reduce the scope of each ticket so items flow faster, or invest time in addressing the technical debt that’s slowing us down.”

Useful Phrases for Engineering Velocity Discussions

• “Our velocity has been relatively stable, averaging around X story points per sprint.”
• “There’s a correlation between our cycle time and our PR review times — when reviews are slow, cycle time increases.”
• “We’re seeing a velocity dip this quarter, largely because of the infrastructure migration work.”
• “Technical debt is a significant drag on our throughput — we should carve out time to address it.”
• “We have limited capacity this sprint, so I suggest we deprioritise the nice-to-have items.”
• “The data suggests our bottleneck is in the review stage, not in development.”
• “Velocity is a team-level metric, not a measure of individual performance.”
• “I’d caution against comparing velocity between teams — the numbers are only meaningful within a single team over time.”
• “Let’s look at the trend over the last ten sprints rather than focusing on a single data point.”
• “We need to distinguish between a velocity dip caused by complexity and one caused by organisational friction.”

Avoiding Common Mistakes When Discussing Velocity

One common mistake is treating velocity as a target rather than a measurement. Velocity is descriptive — it tells you what happened. When velocity becomes a target, teams tend to game it by inflating story point estimates.

In English, you can flag this risk diplomatically: “I’m a little concerned that setting a velocity target might encourage us to over-estimate stories rather than to genuinely deliver more value.”

Another common mistake is comparing velocity between teams. Story points are arbitrary and subjective — what one team calls a five-point story another might call a two-point story. If someone asks you to compare teams, respond: “Velocity numbers are only meaningful within a single team over time. Comparing across teams would be like comparing temperatures in Celsius and Fahrenheit without converting.”

Practice Suggestion

For your next sprint retrospective, prepare a brief velocity summary in English. Write two to three sentences summarising your team’s throughput and cycle time over the past sprint, identify one factor that affected velocity positively or negatively, and propose one concrete action for the next sprint. Practise reading it aloud before the meeting.