top of page

Unraveling the Mystery of Story Points in Agile Part – I

  • Writer: Rashid Akhter
    Rashid Akhter
  • Jan 30, 2024
  • 5 min read

Updated: Oct 14, 2024

Story points estimation is a mystery for new teams. They wonder why we use them, how to use them, and what benefits they bring. This is the first mindset change that new teams encounter. In this two part article I will attempt to Demystify story points by answering some of the fundamental 'Whys' and 'Whats' behind the concept of story point estimation.



Overview: Unraveling the Mystery of Story Points in Agile – Part-I



Q1: Why is traditional estimation incompatible with Agile?


Agile by design is very different from traditional methodologies due to its emphasis on iterative development, flexibility, and responsiveness to evolving customer needs. This distinctive approach poses unique challenges for traditional estimation techniques when they are applied to Agile projects. Some of the issues associated with using traditional estimation for Agile projects include:


  1. Valuing individuals and interactions: Limited involvement of the team in traditional estimates conflicts with the principle of valuing individuals and interactions.

  2. Embracing Changes: Traditional methods, being time-consuming, struggle to adapt to changing requirements, contrary to Agile's flexibility in embracing late changes.

  3. Working software: In Agile, the primary measure of progress is working software, emphasizing outcomes, whereas traditional methods prioritize time-based task estimates, focusing on outputs.


In summary, these issues with traditional estimation methods are at odds with Agile principles, hindering collaboration, adaptability, and the iterative delivery of valuable working software.


History of Story Points


Q2: Is the swift nature of Agile estimation a compromise on accuracy?


Lets join "TAC-Force Sprinters" as they dive into their backlog refinement ceremony and observe what happens.


  • 9:00: All the team members join the meeting and exchange pleasantries.

  • 9:05: Scrum master navigates to the backlog and open the highest priority story.

  • 9:10: Team discusses the story and make sure all questions are answered.

  • 9:15: Scrum Master ask for estimation vote, bingo first show of hands is a consensus.


"TAC-Tastic Coder", who is new to both the team and Agile practices, watches in awe. The 10 minute estimation process unfolds like magic, leaving him intrigued. He can't help but wonder if his team members possess some form of imaginary powers to unravel the intricacies of each story.


Heard about the mindset change? Welcome to Agile :)

It's a well-known fact that Agile estimates are swift, though their accuracy is somewhat compromised. However, there's a good explanation for this. Agile draws inspiration from Lean principles, placing a strong emphasis on minimizing waste by eliminating non-value-added tasks.


As a general principle, all estimation models exhibit diminishing improvement in accuracy as the time invested increases. While story point estimations may lack precision, they prove valuable by saving time, which can then be redirected towards tangible and productive work.


Primary measure of progress is working software not completed Tasks.


Estimation Accuracy by Time Spent



Q3: What advantages does relative estimation offer?

Humans are generally adept at relative estimation. Its straightforward and less time-consuming compared to absolute estimation methods. The approach of comparing tasks relative to each other, rather than assigning specific numerical values, reduces the cognitive load and biases associated with trying to provide precise estimates.


Lets try an example

Take a brief pause, contemplate for a minute or two, and estimate the time required to draw this pencil sketch, that will be your absolute estimate?


Absolute vs Relative Estimates

Now lets give relative estimation a shot. Click to open.


In short, relative estimations are lightweight, and their emphasis on flexibility and collaboration complements Agile methodologies, although mastery may require some practice.



Q4: Why use Fibonacci sequence for relative estimation?

Fibonacci numbers, often referred to as the Golden Ratio, are frequently observed in nature, reflecting naturally occurring patterns. One can identify these patterns by examining the growth of various plants. Many seed heads, pine cones, fruits, and vegetables exhibit spiral patterns, and when these are counted, they often express Fibonacci numbers.


The traditional Fibonacci sequence, given as 0, 1, 1, 2, 3, 5, 8, 13, 21, 34..., is generated by the equation Fn = Fn-1 + Fn-2.


In agile methodologies, a modified Fibonacci sequence of 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 is aligns with the increasing uncertainty and complexity of tasks, providing a simple and intuitive way to estimate relative sizes without assigning specific numerical values.


Fibonacci Sequence: As the size increase small variations become less obvious


Q5: Why can't story points be compared across teams?

Who says you can't compare story points across teams? You absolutely can, as long as both teams meet the following conditions:

  • They should have same skill sets.

  • Working on similar technology.

  • Working on similar product.

  • Similar Work environment.


While it's challenging to find two teams with such extensive similarities, managers often seek ways to measure productivity and make comparisons. A practical approach to understanding team productivity involves two useful metrics:


  1. Sprint Predictability: Assessing whether the team is accomplishing 70-80% of their planned work.

  2. Velocity Trend: Observing whether the team's velocity is improving or remaining stable.


These metrics can effectively identify struggling teams, allowing for timely coaching and assistance. However, it's crucial to use metrics judiciously and with the intention of aiding the team. Misinterpretation or misuse of metrics can have far-reaching consequences beyond a single team and may prove detrimental."


Q6: Can story points be converted into days or hours?

No one converts story points into hours, it's often the reverse. Traditional managers, accustomed to thinking in hours, tend to map their understanding to story points.


While conversions are common in various contexts—Celsius to Fahrenheit, meters to feet, liters to gallons—the same logic doesn't seamlessly apply to story points for several reasons.


  1. Formula will fail Within a team or across different teams, the completion time for a story assigned 8 points can vary significantly—ranging from 8 hours to 16 hours due to diverse skill levels and evolving experiences over time. Attempting to create a conversion formula will fail. The Relationship Between Story Points and Hours

  2. Impact on Continuous Improvement Agile methodologies foster a culture of continuous improvement. An increase in velocity signifies enhanced team productivity. However, trying to fit story points into rigid hourly constraints may lead to questioning achievements when, for instance, completing 80 hours of work within an allocated 40 hours becomes a cause for concern.

  3. Avoiding Micro-Management Converting story points into hours introduces micro-management at the team level and, in some cases, at the individual level. This contradicts the foundational principles of self-organizing teams within the agile framework, jeopardizing motivation and collaboration within the team.




Coming Soon

1 Comment


Rizwan Khalid
Rizwan Khalid
Feb 18, 2024

Very well written and covers the foundational aspects that are equally useful for all experience level. One of the key benefit of modified Fibonacci series over the actual one is that the modified Fibonacci helps emphasize the fact that you cannot calculate uncertainty precisely (otherwise it won't be uncertainty).

Also, a very common error is to convert story points to days or hours. I like the elaboration on the pitfalls of this and it is very handy to have them presented in a nice and compact manner here

Like
bottom of page