How to estimate the Story Points in SCRUM?

If anyone has followed the scrum, then they know that estimating the story points is the most difficult thing to do in the scrum. Different organizations different methods to estimate the story points. Some use the Poker method, while some use the number of hours to get the story done. In this blog, I will explain one such method

Story points are represented with the Fibonacci series (1, 1, 2, 3, 5, 8, 13, 21, 34, 55...). In this article, Mike Cohn explains Why the Fibonacci Sequence Works Well for Estimating. In the above image, we have prepared one matrix which contains the two parameters, Time-Intensive and Story Build Complexity, on which our estimation of story points is based on. Let's take an example:

  1. You have one feature to develop in which you are going to change 1-2 lines of code in the existing function, so your time estimation for this feature will be very low. So you can choose Time Intensive = Low. But the function in which you are going to make the change is used on multiple screens as result the build complexity will increase because you have to make sure that all the edge cases which were considered for all the screens do not break and your own new edge case does not fail. So for this, you can choose Build Complexity = High. So your estimated story points for this Feature should be 3.

  2. Let's take another example where you have to develop a feature from the scratch and it might take you around 3 days or 24 hours to complete the development. So for this, your Time Intensive value can be Medium. Now as this is a totally new and independent feature your Build Complexity can be Medium. So for this feature, your story points can be 5.

If your story point estimations increase beyond 13 then it is advisable that you break down your feature into small tasks and then assign story points to these small tasks.