How many hours does a Story Point equal to?

How many hours does a Story Point equal to?

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)

No alt text provided for this image


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)

No alt text provided for this image

This journey took some effort and time but brought in huge rewards and increasing understanding about wise usage of story points and how they relate to hours?

I hope you can apply this to your own work and benefit from it

Vidyadayini Talapady

Member Of Technical Staff at Percipient.ai

3 年

Thanks for sharing Amitabh!

Anantha Koppa SAFe SPC,SDP, Prosci,MBB

Associate Director (Agile Coach), US Market Vaccines, at Merck

3 年

Great article! I get this questions quite often too! Developers are comfortable in hours and it does take sometime for relativity aspect of story point to get familiar with. Only practice makes perfect and learning from sprints to sprints.

要查看或添加评论,请登录

Amitabh Sinha的更多文章

社区洞察

其他会员也浏览了