How to best use (and Not abuse) Issue Velocity Data
Velocity has taken on several different meanings in the engineering space. Some teams use it to refer to Sprint Velocity (how many story points they'll complete in a sprint), while others focus on specific pull requests and their bottlenecks. Teams measure velocity in various ways: as an absolute number (e.g., Story Points closed), normalized by team size (e.g., Story Points per dev), or over time (e.g., Story Points per dev per sprint). Sometimes it refers to shipped features, reported as Feature Velocity or Epic Velocity. None of these approaches is wrong—they simply serve different purposes for different teams.
There's no universal rule for how teams use Story Points. Some teams consider 8 Story Points achievable in a two-week sprint. Others equate 1 story point to roughly 6 hours of work, or less commonly, to 1 hour. While debates about these approaches continue, they miss the core purpose of Story Points: to help teams estimate and scope work into manageable chunks that can be distributed fairly.
Regarding Issue Velocity, its primary value lies in showing teams how consistently they complete work. This helps understand cadence and capacity—but it's not a performance metric.
Best Practices for Issue Velocity Data
Estimate Story Points for Your Work!
The act of estimating work helps maintain manageable sizes and break down complex tasks into smaller pieces. This keeps momentum strong and work flowing smoothly, rather than getting stuck on oversized tasks. When you notice a Story reaching 12 story points (1.5 dev-sprints worth of work), it's likely time to break it down further. This process can also reveal unclear requirements or differing views about the work's scope.
The breakdown table shows what portion of items have Story Points assigned, helping identify where estimation could be more consistent. Remember: it's more important to estimate consistently than to be exactly accurate. However, avoid overestimating just to "hit numbers"—this skews planning and reduces consistency.
Break Up Big Work Items
Assigning large work items like "Build Feature X" rarely helps anyone. Such tasks often involve uncertain scope, technical debt, and unexpected work. Uplevel recommends using Epics to track larger initiatives while breaking down big tickets into manageable pieces. Teams should aim to complete at least one issue per developer per workday—this maintains flow and prevents massive pull requests that lead to merge conflicts.