Dark side of Story Points & Velocity

In this article which is the summary of my interview with Klaus Meisel , I will discuss the practice of using story points and velocity. More importantly, I will cover the darker side of this practice, which is widely prevalent in many mechanical or "zombie scrum" implementations and also what alternative practice came be used to have better results. So let’s first start with understanding the basic definition and origin of this practice.

???Definitions & Origin

???Story Point

Story points are a widely used estimation technique by teams in software development and specially the ones using Scrum.

• The concept of "story" in software development practice originated from eXtreme Programming (XP). In XP, stories were originally estimated in terms of time, and then quickly shifted to "Ideal Days" - a measure that informally described how long it would take a pair to complete the story if they were not interrupted.
• In general conversations, stakeholders and users would usually speak about ideal day estimations in terms of days, often omitting the word "ideal". This led to confusion among them and the teams. As a consequence, "Ideal Days" was replaced with the term "point", and thus Story Point came into existence.
• An important point to note about story point is that they not have any unit attached to it, i.e. 3 Story Points ≠ 3 (Hours or Days or Months)

???Velocity

Popular definition: The velocity is measured as the number of story points completed in a sprint or iteration.

• At best it is a lagging indicator of capacity

??WHY “Story Point” came into existence

• The main purpose of inventing Story Points was to determine if a work item could fit within a sprint or iteration. A secondary purpose was to establish a shared understanding of these items. This shared understanding was achieved by encouraging conversation and fostering dialogue around the items.
• It was supposed to be a quick and easy activity.

The usability of story points was supposed to end once the fitment and shared understanding were established.

???The Dark side - within the teams -?Story Points Becomes an Anchor ??

• How does a Scrum team handle "carryover/spillover" work?
• When does a Scrum team get credit for the story point that spills over to the next sprint, and how much credit should they receive?
• Should bugs be estimated, or not?
• How should we estimate a time-boxed spike? For example, should a 3-day time box be estimated as 3 story points?
• Can a user story with a story point of 13 be split into two stories with 8/5 points or 5/5/2 points, or can it be 5/5/8, etc.?
• When and how much does a Scrum team get credit for the Story Point which spill overs to next sprint?

In my opinion, these questions and conversations that arise within a team while using story points do not add any value and are a complete waste of time in the overall process.

????The Dark side - beyond single teams

• Comparing: Irresistible temptation of comparing velocity of two teams
• Actual vs Estimated and never ending quest for better estimation (accurate estimate)
• Increasing/decreasing velocity: relating team velocity to team performance
• “Normalising” story points across teams ??, all in the name of easier planning
• Forecasting and predicting: Once story points and velocity are shared with the outside world, including project managers and stakeholders, they often start making calculations, building charts, and creating reports around them. This leads to executive math to determine "when we'll it be done" but this approach is at best a weak idea for forecasting and below is why:
• Velocity Average: forecast made on average, fail on average.
• Deterministic forecast:Forecasts based on the average velocity are communicated in a deterministic tone and have no notion of probability attached to them.
• Forecast in the unit of gibberish: Forecasts made using Story Points are often meaningless because Story Points do not have a unit of measurement. Additionally, Story Points do not represent or relate to the language of the user or stakeholders, nor do they answer the important question of "When will it be done?".

???Alternative and better ways of doing things

• Sizing and shared understanding: start using Slicing & Trimming techniques for work items. If you or your team estimate in your heads without communicating them, then problems with estimates, whether in story points or time, are less likely to arise. However, knowing the difference between "probably small enough" and "probably not small enough" is not the same as knowing the difference between "three days" and "one day".
• Predictability and forecasting: start using flow metrics such as Work In Progress (WIP), Cycle Time, Throughput, & Work Item Age which is already being captured in all modern tools
• flow metrics basically give you the raw data and this data you can use to your convenience for initiating conversations as well as doing predictability or forecasting using Monte Carlo simulation.

???Conclusion

My concern is not with the practice of using story points but rather with the blatant misuse of the idea.

I would like to end this article with the below quotes from one of Ryan Ripley and Agile For Humans, LLC video.

flow-based metrics are a very sharp instrument they can definitely cut deep while story points and velocity maybe are more blunt or crude instrument that if swung too hard could knock you out.

Tools can be used in good or bad ways, so use them carefully. Hand them this very sharp knife that when wielded by an expert can do wondrous things but when wielded by the average person is going to cause a blood bath

?? Credit

I owe a huge thanks to the following people in making this article possible

Klaus Meisel for doing this interview and giving me the opportunity and platform to share my experience. Please do watch the video for a detailed explanation and the story of my journey on this topic. Daniel Vacanti , Ryan Ripley & Todd Miller for giving me the opportunity to be part of the Scrum with Kanban workshop and helping me to understand the concept in greater details.My team "Red Foxes" @ GfK - An NIQ Company for always being experimental and support of new and better ways of working

References

Book

• When will it be done by Daniel S. Vacanti - https://www.goodreads.com/en/book/show/40681093

Articles

• Story Points Revisited by Ron Jeffries - https://ronjeffries.com/articles/019-01ff/story-points/Index.html
• Flow Metrics by Yuval Yeret: https://www.scrum.org/resources/blog/4-key-flow-metrics-and-how-use-them-scrums-events

Video

• The Great Story Points and Velocity Debate - Agile for Humans: https://youtube.com/watch?v=yslSxA_YgFU&feature=shares

Tools

• Actionable Agile: https://actionableagile.com/
• Jira Flow Companion - Chrome Extension