Story point or Effort

Recently, almost of the software development teams are using the scrum methodology as their main development process. And yet for a while that I have experienced in the software development industry, I found that most of the teams who are implementing the process always face one of the very popular questions that has been widely discussed among the agile community which is “Should we use the story point or the effort for estimating a user story”.

Yes, I have faced the same question as well. After I did some researches, discussed with many software teams and even tried to implement both in our team. Finally I have came up with the very solid and qualified answer to that question and I can ensure that “You should use the story point for estimating a user story.”

Before going to the reasons. I would like to share the characteristics of the story point first so that it might make more sense with the supporting reasons of using the story point is better.

Story point characteristics

• Story point is the new unit that is agreed among the team members to use for estimating a user story. So if I was asked “Should we map story point with the effort like 1 story point for 8 man-hours?”, I would answer “Definitely don’t”. Reasons shown below will show you that it will reduce a lot of benefits if you doing so. But if you really want to do, why don’t you just use the effort instead.
• Story point of a user story represents many factors at a time for example, efforts, complexity, risk, etc.
• Story point of a user story is based on the team. It’s team specific. The team A and team B might give the different story point for an exactly same task.
• Story point of a user story is relative with the other user story. For example, the feature “Add to cart” gets 13 story points then the feature that is smaller than the “Add to cart” feature about a half will get 5 or 8 story points.

Reasons why you should use the story point for estimating a user story

1. Non-related with the personal skills

Because the story point is the new unit agreed within your team and relative with other user story. So when we are estimating, it just feels like an answer of a question like “How big this user story is compare to the other user story” and it does not require much skills for being able to do that. You will feel really surprised when you found that even the new grad software engineer gives the same story point to almost the user stories as your senior software engineers who experienced about 5 years give in the sprint planning.

2. Take less time and much more effective

From the reason above, it will also result in the way of the effective in the planning period. The time consumption, discussion and conflicts while estimating a user story will decrease significantly. Moreover, if you have implemented the scrum for the period of time. Finally, the product owner might be able to roughly estimate the user story by himself. Practically, your team will always come up with the requirement that is really familiar with something you have done. In that case, the product owner might just compare the total story point consumed from the previous requirement and use that as the roughly estimated story point for the new requirement. So that he will be able to plan and create the product roadmap much easier and more realistic.

3. Flexibility

Imagine what will happen if we estimated by the effort and then we found that one of the user stories we are doing is taking more time that we estimated. A lot of questions will come up, for example, “Should we re-estimate the efforts”, “Do we have to move some of user stories out of the sprint”, etc. And then will follow by the discussion, meeting, conflict, decision making and finally the ineffective working process. But these all problems will not going to happen if we use the story point because it is just the sum of new unit that the team agree to achieve and complete within a sprint so it dose not matter which task is take too long than expected or which task is take less. We all will just try to keep our commitment and continue working to achieve the goal. Sometimes we work overtime just for closing the user story before the sprint is end. Sometimes we just have a break during sprint when everything going as plan or better than planned. Sometimes we can take more details on some user story when the other are done faster than expected.

4. Monitoring team’s performance

From my opinion, this is the most important reason of using the story point. We can use the story point consumption per man-day to define the performance of the scrum team. Due to the story point is the new unit in terms of how big the user story is. So that when you estimate the familiar user story it always get the same story point over time. If your team completes the same task over and over again, they will be able to get the user story done faster. This will effect the higher story point consumption per sprint (velocity) and this is the tangible metric that represent the team performance. Further more, you can set this as the goal for the scrum team.

Conclusion & Suggestion

From the characteristics of the story point and the benefits shown above, I would say that every software development team using scrum should use the story point for user story estimation. I can ensure that the reasons above are not only the benefits you will gain but you might also find the others while implementing and using in your team from time to time.

Lastly, there are a lot of processes or solutions out there, some teams might not agree with the conclusion above and some might already have a best suit process. It’s fine. Every process is good as long as it is matched with the team and has clear objective of why we doing it. So while you are implementing or developing any processes, always keep in mind the objective of the estimation: It is the framework that helps your team to predict how much works your team might be able to complete within the specific amount of time.