Story point estimation ,conflict resolution

What's happening between each round of estimating? Are the members of the team having a discussion to understand why they are perceiving the work to have a different required effort or complexity or whatever a story point means to the team?

The person who is estimating a 3 has reasons why they think it's a 3 - why it's low effort or low complexity. Similarly, the person who is estimating an 8 has reasons why they think it's much higher in effort or complexity. Are they explaining their thinking? In my experience, it's often helpful to start decomposing the work into tasks and thinking about the complexity - it usually comes out that someone is either not thinking about tasks or someone is thinking about work that isn't necessary.

You may want to look into techniques for facilitating a wideband delphi session. One of the biggest differences is that refinement and estimation in a Scrum Team usually isn't anonymous and there are less forms. But the overall form of a Product Owner presenting a proposed Product Backlog Item, the Developers providing an initial estimate, a discussion to understand why there is variation, and then iteration (including decomposing the work, as necessary) fits quite well with the Wideband delphi techniques.

If they try to roughly sort the items in relation to each other, what happens?

As a Scrum Master you don't solve the issue.  The Developers are the ones that provide estimates for the work since they are the ones that will be doing it.  They are the only ones that can "solve" this issue.

As a Scrum Master you can help them to learn the art of "Disagree but support". In that scenario, talk to them about the fact that this is just an estimate and that as soon as work begins there will be new information gained that would invalidate the original estimate anyway.  Educate them that not everyone will be able to get their way every time.  Ask them if they would be wiling to compromise on a single estimate and evaluate it later to learn from the experience. Help them to understand that the reason for an estimate is to help them identify if they feel it could be done within a single Sprint along with other items that they have chosen.  

Of course, my answer assumes that you're organization doesn't try to use Story Points as a measure of velocity, progress or success for your teams.  If you are doing that, then people are going to hold firm in their estimates because they are giving something for which they are willing to be held accountable. 

Elementary Watson you tell developers that if they want this item in the backlog, some solution should be found

So lets try out other facilitation technique, not just Jira prescribed Scrum poker

Roman voting for example? Thumb up thumb don for each of the story points prescribed, majority vote wins?

Or the "white elephant" game, when they exchange cards with points with each other, if you have time?

Simple presentation, when each is coming out and justifying his position until finding consensus?

Still no agreement?

Suggest them to add the item to the sprint backlog un-estimated, they can estimate velocity any time during the sprint(Jira can wait with their templates and burn down charts). stakeholders want burn don charts? Agree with developers that provisionally the average number will be added to the Jira "issue"

They don't want this solution either? Item goes back to Product backlog then

They dont like this outcome either. Ask for solutions and move to active listening mode.

Team often confuses on the estimation to be just the time it takes. So you as a SM check if Uncertainty, Volume, Complexity have been factored in their estimates. Then do a deep down on based on which factors do they believe it's a smaller or bigger estimates , trying this may surface the underlying assumptions and help in gaining a consensus. And as Daniel said above , arguing too much on something which could change as we learn more while doing the work is not best use of every ones time. 

And if after all these efforts still the consensus is not gained then go with higher estimates and when the tasks for the stories (detailed steps of solutions) are created during planning session, the team might rethink about their estimates . If it still doesn't pave way to consensus then let it be higher or lower estimate and during the execution (Sprint) observe the aging of the story and use this metric or learning as a discussion in the retrospective to improve the estimation techniques.



In my practice estimation is technique to foster collaboration and cohesive thinking on the problem to solve, to build the trust among team members despite of diversity in experience. It's not about deciding a non-negotiable number/ points which the team should be held accountable. 



Please let us know what you have tried and how it helped or failed to build the agreement.

You could consider shifting away from Story Points and instead ask something like: "Do we think we can get this to Done within a Sprint?" Yes or no. If one says yes and another says no - talk through that. Determine what needs to happen in order for it to fit within a Sprint. Turn it into a problem to be solved instead of a story point debate. 

In Scrum, Estimation is done by entire team during Sprint Planning and not only by Scrum Master.

In Scrum, Estimation is done by entire team during Sprint Planning and not only by Scrum Master.

Why would anyone other than the Developers estimate their work?