Engineering Leadership

Story Points Are Broken — And What to Use Instead

Velocity tells you how fast you’re moving the number. It doesn’t tell you how fast you’re delivering value.

Source : Nagaraj

Developers introduced story points as a method for teams to assess task complexity through relative comparisons without needing to specify exact time durations. The original purpose of the solution proved to be logical. The subsequent events that followed proved to be illogical.

Organizations adopted story points as their primary method for assessing employee performance. Organizations used velocity as their method of evaluating employee work output. Teams began to assess their sprint performance by comparing results from different teams and different time periods and different team members. The moment that happened, story points stopped measuring complexity and started measuring whatever behavior got rewarded — which is usually point inflation, scope gaming, and optimizing for the number rather than the outcome.

What Story Points Were Actually Designed to Measure

The team uses story points to assess work according to its complexity and uncertainty that they have experienced with previous tasks. The team uses this measurement system as an undefined unit of measurement which does not depend on specific team components. Your team uses a 5-point story system which does not provide any information about the time required to complete a task on another team with another codebase and another person.

The Fibonacci sequence (1, 2, 3, 5, 8, 13) is used intentionally because the gaps widen as complexity increases. The difference between a 1 and a 2 is small. The difference between an 8 and a 13 is large. This system recognizes that bigger stories become harder to predict because they require more work. The velocity chart which displays average numbers eliminates all the subtle details that exist between the two elements.

The Five Team-Blocking Myths

The Problem with Velocity as a KPI

The team optimizes its work output based on their ability to measure their work output because velocity serves as a key performance indicator. This principle appears in sprint situations through Goodhart’s Law because a measurement that becomes a target function now loses its value as a measurement tool. The team divides stories into smaller parts to increase their completed work count while their estimates inflate to make the number look better, and carryover items get re-estimated down to avoid the appearance of incomplete work.

Cross-team velocity comparison represents the most extreme version of this problem. The comparison between team A’s 40 points per sprint and team B’s 55 points per sprint produces no value because both teams use distinct codebases and their performance metrics and their definition of completed work differ from each other. The only outcome that velocity comparison brings about team A is that it pushes team A to show higher work completion numbers.

What to Measure Instead

The DORA research framework provides four metrics which show a relationship with high-performing engineering teams. Your issue tracker and deployment pipeline can track all metrics without needing story points because all metrics can be monitored through your existing systems.

Cycle time — the time from when a ticket moves to in-progress to when it’s done — is one of the most useful signals. The duration of work is measured through this method which includes all waiting and review and rework periods that story point estimates do not consider. The two engineering goals of average cycle time reduction and cycle time variance reduction both promote healthy engineering practices.

The Four Metrics Worth Tracking

Sprint planning exists to establish dependable work commitments which the team will complete successfully. The actual metrics which determine team performance differ from velocity metrics because most metrics require no story points to be measured.

When Story Points Are Still Useful

The argument to eliminate estimation practices from all projects forever stands unproven by this evidence. Story points exist as a valid measurement tool which enables teams to determine their work capacity during their sprint planning process. The team needs to plan their commitment at 30 points because their sprint performance shows that they will complete 30 points, which makes 45 points an incorrect planning choice instead of a target performance level. The company uses velocity as an internal measurement tool which tracks performance progress but does not provide external performance indicators.

The effective method for using story point planning requires teams to compare work tasks during their planning meeting when they determine their relative value: “This task is roughly twice as complex as that one, so if that one is a 3, this is probably a 5 or 8.” The relative sizing system enables teams to determine their work limits which they can finish within a specific time frame. The system cannot determine how much value was delivered, track team progress, or display team performance comparisons with other teams.

“If your velocity is going up every sprint but your release frequency isn’t, you’ve built a story point inflation engine — not a more productive team. Look at what’s actually shipping.”

A Better Sprint Planning Approach

The team should select specific outcomes for their work instead of selecting a specific velocity target. What work will be accomplished during this sprint that can be shown to others? Which user-facing change will become accessible to users? The new way of presenting information enables people to understand their work capacity because it shows them how much work they can actually complete and deliver.

The actual planning capacity in days provides better accuracy than planning capacity through point system. The team can work approximately 36 developer-days during a two-week sprint which includes one day off for each of the four engineers. The original mapping process provides better task estimation results than using velocity data to determine time through an unstable time-based conversion system.

The tool helps the team plan their work when the team uses story points for their planning process. The system fails to function when it turns into a metric which people use to track their progress to others. The method needs to establish who holds power to adjust measurement standards and who will use those metrics for decision-making purposes.

The organization should maintain velocity as an internal performance metric. The organization should measure its results through external assessment methods. The next time someone asks why your velocity is lower than the other team’s — that’s the moment to explain what velocity actually measures.

Thank you for reading! 👏👏👏 Hit the applause button and show your love❤️, and please follow➡️ for a lot more similar content! Let’s keep the good vibes flowing!