Thuật ngữ Story Points trong Agile là gì? Luyện thi PMI-ACP

After going through the basics of Scrum, the different meetings, the different Artefacts etc., it’s about time we start digging into details of how Scrum could be implemented in a Project.

If you are someone who is not new to Agile Software Development or Scrum, you may have heard the term “Story Point(s)” when people talk about estimates. The purpose of this article is to help you understand what a Story Point is and how you must be using it for your project.

What is a Story Point?

Story Point is a unit of measure for expressing an estimate of the overall effort that will be required to implement the User Story under consideration. Each user story will have a Story Point estimate assigned to it. When we estimate with story points, we assign a point value to the item. The value by itself does not have a meaning and is more of a relative identifier of the size or complexity of the story in comparison to another story. Eg: a story with a 2 story point estimate is perceived to be twice as complex as one with a 1 point estimate.

Instead of assigning numbers like 1, 2 & 3, teams could even assign values like 1000, 2000 and so on. As I said before, the actual number by itself is insignificant. What matters is the relative ratio of the numbers.

What should I consider before Arriving at a Story Point?

As the story point is going to represent your estimated effort to develop a story, the estimate must include everything that could potentially impact the effort. Some considerations include:

The amount of work to do – This is the most important consideration because if there is more work to be done, obviously the estimate will be higher.

Real Life Trivia: For teams that are transitioning from regular waterfall SDLC projects the most common mistake they do is to associate a story point with a fixed duration (either hours or days). Yes, having such kind of a conversion factor makes estimation very easy but that is not Scrum. Scrum recommends that the estimate is a representation of the complexity rather than an accurate depiction of the duration in days the team is going to take to finish the work.

The complexity of the work – The complexity involved in the work we are taking up should definitely be a consideration factor while arriving at the story point estimate. The more complex the work, the higher the estimate will be. As we have already covered volume of work as one parameter, we should be focussing on things like how likely are people to make mistakes while implementing this, do we know everything required to begin work etc.

Risks & Assumptions that could impact the work – The earlier in the life of a Story the estimation is happening, the more uncertainty exists around the requirements because even the product owner is probably still making up his mind about what the product is expected to do. There would be a lot of assumptions and even potential areas for change in the future. All these represent risks to our work and accordingly will result in a higher estimate.

Real Life Trivia: Scrum does not recommend any weightage or order of priority for us to consider among these 3 factors while arriving at the story point number. The team is expected to exercise their judgment and arrive at a number that can help quantify the story’s complexity and work required in a reasonable manner. For example, you could start with a number to represent the amount of work involved. Then you could consider the risks and uncertainties to adjust the number again. The greater the risk likelihood or impact, the greater the impact it is going to have on the number. Then we could consider the complexity of the work to be done. We could consider factors like how much study, trial & error experiments, negotiations with stakeholders etc required during the course of implementation and then adjust the number to arrive at the final figure.

Like I said before, the story point is not a representation of the duration in days or hours but rather is a number that represents complexity. The Story point can be pretty hard to grasp especially if you are someone very used to the waterfall methodology of software development. Nevertheless, if you try to do it for a couple of sprints, you will get the hang of things and should be able to take things forward the Scrum way…


Story Points are a fixed and relative value of development effort

  • Story point estimations should include all works involved (i.e. research, risks, analysis, actual work, etc.)
  • The story points scale is based typical on Fibonacci sequence (1, 2, 3, 5, 8 which corresponds to S, M, L, XL, XXL)
    • The Agile team can tailor the scale as needed
    • 2 story points carry the equivalent of twice the amount of work of 1 story point
  • The sum of all story points to be completed in one iteration is the velocity for the iteration
  • Story points can be re-estimated later, but the accuracy of Agile metrics like velocity will be hampered
  • Benefits of making use of story points:
    • Can motivate team members to achieve more story points in a fixed time (rather than telling the team has achieved 130 hours of work last week, it makes sense to tell them they break the record of 42 story points last week)
    • Avoid Pakinson’s Law (work tends to expand to fill up all the available time)
    • Avoid Student Syndrome (wait to begin work until the deadline is imminent)
  • notes: the sum of story point estimates of all user stories of an epic may exceed that of the epic because after decomposition, the estimate is more accurate
  • A zero story point user story is said to be of minimal effort for a development team
  • User stories are to be broken down into tasks during an iteration. It is appropriate to estimate tasks both during iteration planning and throughout the iteration.


As someone who transitioned from regular Waterfall Software Development to SDLC, a big problem for me and the team was moving away from estimates in Man Days and the urge to have an “Accurate” estimate for the user stories under consideration. Yes, it was very hard to give up on old habits and we eventually did it because it was beneficial in the long run.

We are going to talk about 5 reasons as to why we must use Story Points and not Man Days when we do estimation for a Scrum project.

Reason 1: It Avoids the Need for Frequent Re-estimation

This is probably a very big benefit for the development team. In most projects, when we do estimation during the planning stage, not all information is available up front and the estimated values consider a lot of assumptions. As the project work begins and clarity emerges, people realize that the originally estimated numbers wouldn’t be enough and the team needs more time to do the implementation. This results in a lot of over-time and stretching from the team in order to meet the deadlines. Yes, an easy argument here is to have the estimates done more accurately but this is easier said than done. I have been working on software projects for the past 12+ years and trust me, even the most experienced developers make mistakes while estimating which is why the story point concept is much easier.

When you provide an estimate in story points, the number does not represent a finite amount of time. It represents a relative complexity and hence if the team identify an extra task or two during the course of development, we don’t need to provide a re-estimation for the entire user story. This makes life a lot easier for the team because they don’t have to worry about the reaction they will get every time they identify something new that needs to be done. This is all the more beneficial because in iterative software development, you learn new things about the product and how you can implement it with every passing iteration with fear of being reprimanded or being forced to stretch to finish the tasks.

Reason 2: It helps to Reduce the Team’s Fear of Commitment

One of the biggest drawbacks of traditional waterfall method of software development is that the team is almost always forced to finish the work (and even the extra work that gets identified during the course of development) because they committed at the start of the project that, work will be completed. If we are asking the team to estimate in days for a user story, we are basically doing iterative waterfall where we are forcing the team to commit to deliver a certain man days’ worth of stories in an iteration. By eliminating this need to estimate in days for a story and replacing it with story points, people are under less stress and hence they are more likely to think rationally and even provide better estimates. This is because, when you estimate in days, a fear of whether I can finish this within the X days estimate is always going to be running in the back of the mind of the person doing the estimation and may be counterproductive.

Reason 3: It is Faster

As a continuation to the previous point, before a team arrives at an estimate in man days, they take into account the various issues they may face in future and take a lot of time before finalizing on the number. This typically takes a few days or maybe even more if the story being estimated is quite complex. However, if we are asking for a story point sizing, the team will be able to give a reasonable number much faster because the sizing is relative and doesn’t reflect a fixed time duration.

Reason 4: It does not give a False Sense of Certainty

As with any IT Project, what we plan at the start and what we finish with are two entirely different entities. Things change and we don’t have any choice but to roll with it. That is one of the strong points of Agile; it allows us to Adapt to change. Anyways, getting back to the point at hand, when we estimate a user story in Man days it kind of adds a certain level of Certainty about when the story will be completed. In reality there may be many assumptions that went into the estimate or dependencies that weren’t considered which could require a re-estimation some point down the line. By having estimates in story points which cannot be directly translated to a fixed man day figure, we don’t provide that false sense of Certainty that man days carry.

Reason 5: It encourages collaboration

In order to understand this point, you first need to understand what Planning Poker is.

Scrum recommends that we follow an exercise called Planning Poker to estimate user stories. Each team member is distributed a set of poker cards that contain the Fibonacci numbers. After reviewing each user story, all team members are asked to choose a card from their deck that would signify the estimate for the story per their understanding. The cards kept face down so there is no Peer Pressure. Everyone reveals their cards at the same time and the person with the lowest & highest estimates are asked to explain the rationale behind their estimates. After this, we repeat the exercise until the estimates converge towards a number that the team is comfortable to assign to a user story.

As this Planning Poker exercise is a team effort, the team get to share constructive criticism, have healthy debates and more importantly have fun working together as a team. Good scrum teams use the planning poker exercise of story point estimation as an opportunity for team building and encourage collaboration among members of the team.

As you can see, estimating with Story Points has many advantages. Of course, people who have extensive experience in working on waterfall SDLC projects may have difficulty making the transition from man day estimates to story point estimates. But, if you put in the effort, the results will definitely surprise you because, the benefits I have explained above are not just bookish or theoretical hoopla; they are based on personal experience when I made the transition to using Story Point estimates on my Scrum Project.

Leave a Reply

Tôi rất vui khi bạn đã quyết định để lại comment, tôi sẽ phản hồi tất cả các comment nhanh nhất khi có thể. Chú ý tất cả comment đều được kiểm duyệt cẩn thận, xin đừng cố gắng spam hoặc quảng cáo. Xin cảm ơn.