Velocity is often a term used in the process of sprints it tells the general rate how many tasks/tickets we complete in a sprint. A sprint is standardly 2 weeks long, while some can be shorter like 1 week or longer like 4 weeks. Velocity in terms of software development measures the amount of work a Scrum team completes in a single sprint, typically expressed in story points, and helps forecast capacity and plan future sprints. (according to AI search).
The idea is to allow the team to see rate of speed they complete work. This sometimes tell us how much work is completed but not necessarily if we are bringing value. Correlation doesn’t always mean causation, so what’s important is the trade-off for the work items creating value for the company or project. We can often tell this by customer feedback and the lessening of production errors.
Sustainable velocity depends on the team dynamic, team goals, and/or demand by Product Owners/Customers. We all like to get things done fast generally, but without sacrificing our teams health and long-term maintainability. There’s a point of diminishing returns, when working at a high velocity you start to see more mistakes and errors, and loops back to already defined tasks that need reworked. What makes sense is to be effective but not burn out the team. The return you achieve for sustainable velocity than a too high of velocity outweighs the benefits of just feeling like you’re getting things done fast. It can be an illusion or just have the feel-good feelings when you see so many points completed in sprint, when really the question is, is the work beneficial? Did it solve any problems or prevent future ones? You have to use these questions to think about whether the velocity is actually making an effective change or expected outcome.
One good way to maintain a sustainable velocity is understand developer’s output at a certain velocity, find a comfortable pace and stick with that. This all depends on the team or organization, but generally you want to sustain a velocity where developers can still work, communicate, have time to think, and or have some heads down time. Delivery for the sake of deliverables isn’t the idea. You want to hear or see good feedback from your sprints, dependent on that this may require a change in direction or whether or not work on something different. Perhaps start on a different epic, or work on something more high priority. If developers are agreement with the pace, keep at it, but always be mindful that pace can vary, and as long as your bring value you are golden.
