Our development team's Velocity is erratic, making long-term planning difficult. As a new Scrum Master, how do I effectively measure this metric, and what are the top 3 non-technical impediments or process issues I should look for outside the Sprint to help stabilize and improve the team's ability to deliver value and maintain a predictable Scrum flow?
3 answers
Velocity is measured by summing the size estimates (Story Points) of the Product Backlog Items (PBIs) successfully completed and accepted within a Sprint. To stabilize and improve velocity, the Scrum Master must look for non-technical impediments, focusing on the following areas: 1. Poor Product Backlog Refinement: The team starts Sprints with poorly understood, non-ready items, leading to mid-sprint scope creep or blocked work. This is the biggest velocity killer. 2. External Dependencies and Interruptions: The team is constantly pulled off Sprint work by stakeholders or external teams. The Scrum Master must actively shield the team and resolve these organizational impediments. 3. Unstable Definition of Done (DoD): If the DoD changes mid-sprint or is vague (e.g., "Tested" without specifics), items are often pushed to the next Sprint, artificially lowering velocity. By fixing these systemic issues, the Scrum Master establishes a more predictable Scrum flow and improves long-term forecasting.
Identifying and resolving external interruptions is huge for stabilizing Velocity. But how does a Scrum Master effectively quantify the cost of those interruptions to leadership? Should the team start assigning Story Points or time estimates to the interruption work, or does that undermine the commitment to the Sprint Goal and the overall Scrum framework?
To stabilize Velocity, a Scrum Master must enforce a strict Definition of Ready during Product Backlog Refinement, shield the team from External Interruptions (impediments), and maintain a consistent Definition of Done (DoD). These actions increase predictability in the Scrum process.
I agree with Henry. The simplest way to start improving Velocity predictability is to ensure all work going into the Sprint is actually ready and well-understood. Good Product Backlog Refinement is the Scrum Master's secret weapon for a stable Scrum flow.
Charles, you should avoid pointing interruptions as it can incentivize accepting interruptions. Instead, the Scrum Master should use the Sprint Review and Retrospective to quantify the impact in a business context. Show leadership the list of promised PBIs that didn't get done because of the time spent on un-planned work (interruptions). Track the total time lost and present it as a reduction in realized business value, not just a metric fluctuation. This frames the issue as an organizational impediment to the Scrum flow that must be resolved at the management level.