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.

Navigating Nuance: Specific Language for Feedback & Prioritization

Okay, so we’ve covered the broader concepts of engineering velocity – essentially, how much value your team delivers. But translating that into clear, effective communication in English, especially when you’re not a native speaker, can feel incredibly tricky. It’s one thing to understand the idea of “increased velocity,” but quite another to articulate it confidently during a code review or when proposing a new feature. A key area where nuances are often lost is around framing feedback and prioritizing tasks – this is where precise vocabulary becomes crucial.

Let’s consider a common scenario: you’re reviewing a pull request submitted by a colleague. The PR itself looks reasonably complete, but the reviewer notices several minor issues. Instead of simply saying “This needs work,” which can feel vague and unhelpful, try phrasing it more constructively. Saying “I noticed some potential performance bottlenecks in this section – specifically, the loop’s complexity could be improved to reduce execution time” is far more targeted and actionable. Pay attention to words like bottleneck, complexity, and execution time; they represent specific technical terms that convey a much clearer picture than general statements. Similarly, when discussing prioritization with your team lead – perhaps suggesting a new feature should be tackled after the current sprint – avoid saying “This is important.” Instead, explain: “Given our current velocity and the upcoming deadline for [Project X], I believe prioritizing this feature would allow us to meet the target release date while maintaining a healthy sprint capacity.” Using terms like velocity, sprint capacity, and target release date demonstrates you understand the bigger picture.

Another common pitfall is using overly enthusiastic language when describing progress. Phrases like “We’re crushing it!” or “This is going amazing!” – while perhaps well-intentioned – can sound unprofessional in a formal engineering environment. It’s better to focus on concrete metrics and demonstrable results. Instead of exclaiming about success, try stating: “The recent refactoring resulted in a 15% reduction in response times, as measured by our monitoring tools.” Focusing on measurable improvements is always more impactful and provides a solid basis for discussion. Remember, clear, concise language builds trust and ensures everyone understands the current state of affairs.

Finally, remember that active listening plays a huge role. Don’t just focus on formulating your own response; genuinely understand what others are saying before you react. Asking clarifying questions like “Could you elaborate on the reasoning behind this approach?” or “What metrics are we using to assess the impact of this change?” demonstrates engagement and helps bridge any potential communication gaps. It’s about building a shared understanding, not just broadcasting your own opinions.