In agile, teams estimate stories (or any PBIs) in relative terms rather than in an absolute measurement (such as number of person-hours). The most common unit of relative measurement is a story point. The number of story points attributed to a backlog item should reflect the following:
Volume - How much work it is.
Complexity - How hard it is.
Uncertainty - How much is not known about it.
The whole team participates in estimating (sizing) the teams backlog items. Team estimates increase accuracy by including all perspectives, build consensus within the team, and creates a shared commitment. Estimates reached by consensus among those who actually do the work being estimated are more accurate than those given by managers, architects, or others; and are less easily influenced or overridden than individual estimates.
We are much better at estimating relativity than precise units. We can usually estimate this way both faster and with more confidence. As you work through one task, it becomes simpler to adjust future expectations based on the relative scale you gave them with story points.
Working with story points is a lot more complex than this, such as making sure marbles don’t become associated with story points, but I hope this helps clear up some of the mystery behind why using story points is so valuable to estimating projects.
For virtual teams you can use you can use the below link.
For in person Teams you can use the below method.
Pick a sequence of numbers. (Most common are the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, 34, ... .)
Give every team member a deck of cards, with one card per number.
The Product Owner reads out the story.
Estimators privately choose a card to represent their estimate.
Cards are turned over simultaneously.
Discuss differences.
Re-estimate.
If you've got a team new to relative sizing and are stuck on the idea that numbers should mean number-of-person-hours, try affinity estimating instead.
Write the story headings on sticky notes and place them on the wall.
Ask everyone on the team to re-arrange the stickies in order of increasing estimates (volume, complexity, uncertainty). No numbers are involved here, just ordering that A seems bigger than B, and so on. Also, not everyone needs to agree on the order. We're not done yet.
Have them group the stories into T-shirt sizes (XS, S, M, L, XL).
Check for consensus, discuss differences, and adjust as needed.
For basic capacity-planning purposes, it would be fine to stop here. (Over time, team can learn how many smalls, mediums, and larges they can collectively accomplish in a sprint.) But T-shirt sizes don't lend themselves well as metrics for demonstrating velocity.
So, if the team will now allow it, assign Fibonacci sequence numbers to each category (e.g., an XS is a 1, S is a 3, M is an 8, L is a 34, and XL a 55). Again, the important thing is not that everything that is a Medium is equally time-consuming, complex, and risky; it's that the Mediums are more so than the Smalls and less so than the Larges.
Resources:
Estimate an issue: https://support.atlassian.com/jira-software-cloud/docs/estimate-an-issue/
Planning Poker playing cards.