How can you choose the best agile estimation method?

The key point is - do not ever equate story points to hours. This is fundamentally against agile principles and yet it's so common in practice. Treat story points as story points and refine the estimates based on actual velocity & and the burndown chart.

well if its size and experience then as maarten said they probably have their own references to size stories, for me personally i opt for t-shirt sizing with as you say smaller teams, but its not just the team its the organisation that you must take into account too, i think fibonacci for me atleast is outdated to a certain extent in a highly technical organisation it does to a certain extent make sense, but for the sake of transparency depending on the product that is being worked on xxs, xs, s, m, l, xl,xxl would work fine

Estimation are relative that depends on mindset that team is having to decide on estimation techniques.For couple of sprint observe if it is working then go for it.Large team need to split into multiple small teams

Team size and experience surely do play a crucial role in choosing the estimation method. However, any method chosen should encourage discussion and learning even if the team is a very mature one and if there is historical data and feedback present. Also having a faster and a simpler method can benefit big and mature teams as well. So no matter what's your team size and experience, you should strive for constant learning and discussion while still trying to maintain a fast and simple way to do the estimation for the whole team to be on the same page and have the same understanding about the estimation process.

Estimations are relative meaning each team has its own way to estimates. Preferred method of estimates is more depended on mindset of team. Best way is to check couple of options with team over the period of time. for each option evaluate what are the problems team encounter. with couple of iterations and having comparative result, team will able to find best and more appropriate method for them. Continue with same method unless new problem arise.

well decomposing your story down to its small bite size piece is in fact an art, if it wasn't then all stories would be a 1 pointer or an xs etc etc, in this specific circumstance i would potentially for at least that uncertainty stage pick out a preliminary sizing form such as t-shirt sizing those high level requirements ( at a PI planning session for example) and then use if relevant Fibonacci when it is refined at your team level

Stakeholders don't give a *bleep* about your estimation approach. You give them a date, and you keep them updated on progress. That's what they care about. They don't care what is under the hood. Whether you use Story Points, Ideal Days, Monte Carlo Simulation or Gummy Bears. They'll only begin caring the moment your forecasts turn out to be wrong :-).

The stakeholder concern is almost always... WHEN, they do not concern themselves with how you will at team level estimate the story. if it is a team with good transparency, then the stakeholder would have access to the wall of reference ( some may understand those reference stories.., or not) to just have some perspective of WHY a bit of work may take time to complete, or i do like to invite stakeholders to a refinement to further clarify which again is the extent of their involvement as far as interaction with the team is concerned, as for their influence on how the team may choose to estimate..., none

Planning poker estimation method is designed in a way to encourage the whole team discuss each individual task, even if one is not directly involved in it. It gives individual team members an additional space to be on the same page with others, understand each other's tasks better and eventually helps the team to work on a common goal and understand how each individual task contributes to that goal.

Story Points represent effort. Complexity, risk and uncertainty influence effort, but each alone is not alone to determine effort.

One big advantage of estimating using planning poker for me is actually getting the team to common understanding, getting the team to THINK and DISCUSS together, this adds more value than the estimate itself.

When applying this method, I usually pick up the largest point and smallest point (or outlier point) and ask them why they think the point is like that. They might have a very different view from the others that we might drop out.

T-shirt sizing proved to be the better methodology while applying to individual Portfolios for prioritising projects we would do for the year

Whether the estimates come in a form of a t-shirt size, fibonnaci numbers or any other unit, the key point is that the whole team should have the same common understanding about the mapping between the unit of estimation and the effort which it represents.

for me its a purely PI sizing tool, that is finger in the air, you cannot ( unless you work on a simplistic website) use this at the team level this estimation method is great when sizing a task to give a huge audience an idea of how hard or easy it is but would'nt work in all cases at a team level

One of the criteria that makes this method more accurate is that the team needs to agree on the sizing of the smallest task. For example, they could agree that creating a button is the smallest task and assign it an XS size. Then, they can use that as a baseline to estimate the size of larger tasks.

Velocity is not an agile estimation method. This paragraph is flat out wrong. Velocity can be used for forecasting, but the estimates are usually generated using Story Points and Planning Poker.

Its not something used to estimate at all, unless you want to say estimate how much a team can accomplish within a sprint based on the past performance.., like most things these metrics are good for indications but should be taken with a pinch of salt, as the unknowns that can jump in would drastically change that ( time off, dev sick for a couple of sprints etc )

Velocity is not used as an estimation, or well, to be detailed, Velocity can be sued to forecast on delivery, based on historical performance. but Velocity cannot be used by a team for estimation during a sprint or an iteration, however, it could be of interest to top-level management or strategists. but not to the team who needs to make it through the sprint

Velocity is something that can be very heplful during the estimation process, but it is just an additional helping factor for the team in addition to their experience, depth of understanding of each individual task, the effort it represents and their ability to collaborate, discuss and come to a common understanding during the estimation process, but it does not represent the estimation process or a method itself.

I'm not sure I agree with you, Maarten. While pure speed might not be directly related to agility, it is indirectly connected. This is because when using poker planning or story points, what is fundamentally happening is measurement based on task complexity combined with the team's velocity. This ensures a genuine effort in the project and creates something tangible to be reflected in a work calendar.

Choosing the best agile estimation method: 1. Assess team expertise. 2. Evaluate project complexity. 3. Consider time constraints. 4. Explore methods like Planning Poker, T-Shirt sizing, and Affinity Mapping. 5. Experiment and adapt to find the most suitable approach.

In the spirit of "Yesterdays weather" you could simply count the number of items/stories delivered in past sprints. Everything being equal you will be surprised to find, in an established team, this is just as good an indicator of what the team is capable of. When running this in parallel with standard estimation practices I was surprised to see how reliable this was. It begged the question, why are we spending time on estimating during sprint planning?

At the end of the day, the agile teams should be agile enough not to constantly stick to a fixed estimation method, process or any other paradigm. Being collaborative, constantly learning, reflecting on the past experience and improving the estimation process which best fits your team is the key.

Try out Ideal Days. Story Points are confusing, and riddled with misconceptions. Managers think #NoEstimates is scary. Ideal days work fine, without the downsides of Story Points and you can still use relative estimation like Planning Poker.