Much of Scrum's value to an organization is in creating transparency. 100% agreement isn't the real point of planning poker; the goal is actually to narrow the cone of uncertainty around feature estimates as much as possible, and to make the level of effort and potential project risks of each story visible to stakeholders through their chosen proxy, the Product Owner.
Planning Poker Can Have Multiple Rounds
As explained on planningpoker.com:
It is very likely at this point that the estimates will differ significantly...If estimates differ, the high and low estimators explain their estimates...The group can discuss the story and their estimates for a few more minutes...After the discussion, each estimator re-estimates by selecting a card.
The point is that you can keep re-estimating as long as opinions are converging. The key, of course, is that people need to talk about why their estimates are outliers, so that the team can consider this information when re-estimating each round. If you still have outliers after discussion has been exhausted or when the time-box has expired, then you have to use your team's defined process to find a reasonable compromise.
Options for Compromise Within the Team
You can do whatever seems reasonable in such cases. Generally, teams agree beforehand on a compromise process, but it's okay to change it on the fly so that the end result is always somewhat reasonable.
Some options for compromise include:
- Discard outliers, then calculate the mean. This is usually my preferred method when a story has been properly decomposed.
- Calculate the average, including any outliers.
- Split out contentious tasks into separate-but-dependent stories that can be estimated separately.
- Remembering that estimates are educated guesses, not promises written in stone.
The bottom line is that the team can (and should) make its best guess and move on. If the team can't build a consensus, or at the very least agree to disagree, then you may have an underlying problem with the quality of the story being discussed.
Options for Compromise With the Product Owner
Sometimes the problem is the story being estimated. A key point here is that all stories must be estimated to see if they fit within the current sprint, but the stories you estimate don't have to be verbatim copies of the current Product Backlog items.
Remember, the first half of Sprint Planning involves the participation of the Product Owner, so a contentious story estimate is a perfect opportunity to work hand-in-hand with the PO to re-scope or refactor stories which have potential issues. The PO can work with the team to split or rewrite stories, or re-prioritize the Product Backlog on-the-fly to swap in a different story that fits better within the current sprint.