Measuring True Velocity: Accounting For Incomplete Work In Scrum
Velocity measures the amount of work a team can complete within a sprint. However, only counting “done” user stories fails to show the true velocity of a team. Partially completed work still requires effort and pulls focus from finishing other stories. By quantifying and tracking incomplete work, teams can adjust their velocity to set realistic sprint goals.
The Problem of Incomplete Work
Velocity traditionally only accounts for fully completed user stories. While simple in concept, this approach has flaws in practice.
Why tracking “done” stories fails to show true velocity
Counting only finished user stories hides the effort spent on partially complete work. A team may consistently have 20% of stories spill over into the next sprint. Their velocity appears stable at 8 completed stories per sprint. In reality, a significant portion of capacity is spent continuing unfinished work.
This invisible effort creates an illusion of high productivity. As new work piles on incomplete stories, velocity will suddenly crash. This causes frustration on the team and erodes trust from business partners. Failing to measure true throughput results in poor planning and coordination.
The challenges of quantifying partial progress
While essential for accuracy, quantifying effort on unfinished work has difficulties.
Teams dislike tedious tracking of detailed subtasks. Also, the level of completeness can be deceiving. A story may seem 90% finished, requiring only cleanup and testing. Yet, integrating and validating code can reveal overlooked dependencies or defects.
There lies a natural temptation to simply wait for stories to meet the “definition-of-done” before counting them. However, ignoring true throughput limits the ability to forecast team capacity, staff projects, and set sprint goals.
Accounting for Incomplete Work
Precision matters when planning complex projects with multiple interdependent systems, teams, and milestones. Tracking unfinished work creates transparency into where teams overload and where processes slow throughput. Two techniques help quantify partial progress to influence sprint planning.
Using story points for finer progress tracking
Story points classify user stories into small, medium, and large buckets. Teams apply points based on estimated complexity and completion time. This allows summing effort across stories of differing content and sizes.
To track unfinished stories, assign partial points based on progress. For example, a 3-point story completed halfway would tally 1.5 points that sprint. Add up points from done and partial stories to calculate total throughput.
When consistent, story points measure output more precisely than counting only finished items. Granular tracking helps identify where stories get stuck and capacity constraints occur.
Adjusting velocity based on incomplete work
Velocity, calculated over several sprints, forecasts how much work a team can handle. It traditionally only accounts for fully done stories. Factoring in progress on incomplete stories yields velocity more accurately reflecting throughput.
For example, a team that completes 8 stories (20 points) each sprint has a velocity of 20. However, 12 additional story points roll over >50% complete each sprint. Their true velocity is closer to 32 points (8 completed stories + 12 partially completed points).
Adjusting velocity prevents overburdening the team with excess work during planning. It helps pace incoming requests and staffing to actual capacity, reducing unfinished work piling up.
Setting Realistic Sprint Goals
Unfinished work cannibalizes capacity meant for new items. Factoring partial progress into velocity calculations grounds sprint planning into reality rather than wishful thinking.
Planning capacity based on historical data
Teams often use yesterday’s weather when packing for tomorrow’s picnic. Velocity baselines throughput to anticipate upcoming capability. Reflecting partial progress will lower velocity, providing realistic input for setting sprint goals.
For example, if velocity drops from 32 to 22 adjusting for continuous incomplete stories, use the lower figure. This lessens the chance of overload and interruption mid-sprint to re-plan and reprioritize.
Leaving room for unfinished work
Past behaviour predicts future performance. Assume stories will spill over and allow flexibility for unfinished work each sprint.
Scrum masters can account for this by influencing the sprint commitments. If velocity is 22, she could guide the team to plan for 18-19 story points, allowing 3-4 points to cover unfinished work.
This sprint padding lets the team focus energy on completing rather than continuously starting new stories. With more finishes each sprint, velocity will begin reflecting true capability.
Achieving Consistent Velocity
Variation damages forecasting models dependent on stable averages. Large swings in completion rates misrepresent capacity. By achieving consistent velocity, teams improve predictability, trust, and flow.
Balancing work-in-progress
The team swarming from shiny object to shiny object leaves many stories nearly complete but few actually done. Limiting work-in-progress caps context switching and multitasking fallout.
When teams shift focus too frequently, they lose time in cognitive setup rebuilding situational awareness. Constraining new story starts until existing work finishes reduces this thrashing.
Reducing context switching
Frequent context switching cuts productivity up to 40%. Each time the mind changes gears, momentum stalls reorienting on a new work stack.
Business partners anxious for updates continually interrupt software teams. Every distraction and meeting sidetracks focus. Priority churn almost guarantees partial progress and incomplete work.
Scrum masters can mitigate disruption through fewer longer meetings, noise-free focus periods, and visual signals protecting team members. A consistent sprint cadence also builds momentum.
Applying focused development
Focused development emphasizes finishing user stories before starting new ones. Limiting work-in-progress and context switching provides the space to focus deeply on story completion.
Visual controls give transparency whether each team member works on one or multiple stories at once. Public commitment to restraint from starting new work until finishing existing also instills discipline.
Focus and consistency create conditions allowing teams to establish repeatable velocity critical for industry standards such as SAFe forecasting models.
Continuous Improvement Through Retrospectives
Inspecting throughput of completed and partial stories during retrospectives diagnose areas for process improvements. This gradually grooms more consistent velocity sprint-over-sprint.
Reviewing partly done work
Including unfinished stories as input during retrospectives shifts conversations from vague abstraction to tangible examples.
The team can pick recent instances of near completes and do deep analysis into the “why”. The collaborative environment removes any blame, encouraging honesty about roadblocks faced.
Common themes emerge around priority thrashing, external dependencies, skills gaps, or dates slipping from underestimation. Discussing actual stories makes the dynamics visible.
Finding the root causes
Simply acknowledging the incomplete story volume does not remedy the situation. Retrospectives provide the forum for finding root causes slowing true velocity.
Leverage quality improvement tools like the 5 Whys, fishbone diagram, or 5-Step A3 to probe past symptoms to the source factors. While inconvenient in the short-term, this reflection strengthens systems limiting throughput.
Making process changes
Ideating solutions comes naturally when the team shares ownership of current state results. They know the context best to brainstorm fixes matching reality not assumptions.
Each sprint, try small changes targeting factors uncovered during retrospective analysis. Preventing one story from going incomplete has compounding effects long-term. Velocity metrics confirm when adaptations lead to less partial progress.
Continuous improvements towards stability allows teams to become predictable, lowering risk and frustration for everyone involved.
