In Scrum, estimating product backlog items, also known as sizing user stories, helps the development team determine how to commit for the Sprint. Only the people that will be doing the work are expected to estimate it. By agreeing to how big product backlog items may be and subtracting it from their total sprint capacity, the team can commit to delivering a certain number of product backlog items in the upcoming Sprint.
Also, by knowing the average number of estimated units the team has delivered per Sprint (velocity), Product Owners can draft a plan for what will be included in the upcoming release(s). The process of creating the plan is known as release planning.
Scrum does not require you to estimate in points. As long as you can provide an effort estimation, you may do it. Often, teams are pushed into using time units, such as days to estimate the work. This is because it is easier for us to estimate effort if we can calculate how long it will take to complete it. It is also a standard accounting unit. There are, however, pitfalls when using time to estimate the work.
1- Wrong expectations - When estimating in days, we fall into the trap of calculating in hours, in other words, when the work will be done instead of how long it will take to complete the work. The former is calendar days; the latter is ideal days. A calendar day refers to the time when the items will be completed, considering interruptions. An ideal day refers to the time it will take to complete an item if there were no interruptions. Interruptions tend to happen regularly. Therefore, calendar days and ideal days are not interchangeable. Estimating in points helps us to separate the two and avoid creating the wrong delivery commitment.
2- False sense of precision – It turns that we are better at relative estimation than we are at absolute estimation. By estimating using a predetermined number sequence, such as the Fibonacci series, and comparing it to something we have completed in the past, we can estimate effort with a relatively high level of accuracy.
3- Time estimates take longer – A case study conducted at Microsoft showed that when using point estimation the estimates were 4 times more accurate than their counterpart time-based estimate.
4- Difficult to reach consensus – It takes less time to agree if something is 40 or 100 points than it is to agree that it takes four days or five days to complete. That is because the order of magnitude that points can offer make the conversation easier among team members. Also, team members are more likely to agree that feature X is larger than Y, if they are not held to a specific time commitment. Remember to pick a baseline feature to compare all other features. This is also known as calibrating.
Keep in mind that relative point estimation does not feel intuitive at first. It will take a few sprints to feel comfortable. Over time, the team will get better at it. In the meantime, it is important that they feel free to fail by reinforcing that there are no wrong answers and that this is their best estimate.
