Story points were meant to be abstract. This abstraction helped bring a discussion back to work (size, complexity, bigness, etc.). In the absence of story points (in the earlier days), people would often argue about hours, leading to a lot of emotions around time.
A real time scenario between my Boss and me is presented below (took place many years ago):
Boss: Amit, here’s a new project [explains for 3-5 mins…].. How much time can you complete this in?
Me: Boss, you just laid it out, at least give me a day to think it through
Boss: We need to respond today, $3M are at stake
Me: [Confused and frustrated] How about 2 years
Boss: [Almost in anger] You will lose your job and I will lose mine too!
[…the argument continues for the next 60 minutes. ]
Finally:
Boss: So we agree it can be done in 6 months right?
Me: [With a defeated expression…] OK
Project was finally completed in 10 months. Low quality, frustrated team and unhappy customers..
Coming back to the point: When I learnt and understood Story Point estimation and how to use them effectively, the same situation resulted in discussing work, whenever there was disagreement on a large work estimation(e.g. project estimation = 300 points).
If understood correctly and used wisely, story points and how they relate to hours can be a powerful tool for Agile teams to help improve their estimation accuracy.
Let me try to explain this point (the relationship of Story Points vs. Hours) with an actual scenario below
In the image that I have presented below, you can see how team members can reflect on the past estimations and relate to the amount of time spent on different stories.
Feedback from such data has helped my teams improve their understanding of estimations, and have powerful conversations leading to estimation accuracy.
Understanding how to use this artifact:
Y axis – Relative Sizing(Story Points)
X axis – Time ( Hours)
After completing 4-6 sprints with a team, I would plot this data and would organize an estimation retrospective with them.
Such data provided deep insights –
1. One was on how different story point (SP) ranges compare to each other in general. New teams often found that the SP to Hour ranges were long and that there would be huge overlaps with adjacent SP ranges (shown in red circles in image 1)
2. They also noticed that there were a number of odd stories – the ones that would penetrate deeply into the next higher or lower SP range. These needed more conversations and better understanding. (marked with red circles)
3. The team would then identify similar stories in the upcoming or future sprints and often re estimate them after conversations
4. This helped evolve the Story Point to Hour ranges to be more compact and they overlapped more towards the edges (As shown in green in Image 2)
