How should a team handle disagreements about story-point estimates in Scrum?

Question

During estimation, the Product Owner presents a user story that seems clear to a team that usually knows their strengths and weaknesses, and that is not hostile. What should the Scrum Master do if the story is judged very differently by the team members, but they can't convince each other enough to agree on a story-point estimate?

For example, let's say two opinions arise. Some see this as a rather easy story (e.g. 2 points) and others foresee technical complications and judge that the story should be 20 points. The 2-point voters say, "I understand your opinion, but don't think those complications are valid." The 20-point voters say, "The past tells us that these things are always a lot more complicated then they seem."

I assume that if the issue is not clarified the 20-point faction will not commit to the user story if it is (in their eyes) under-estimated.

What should the Scrum Master do in this case? Go for the average? Choose the worst case? Or accept this user story as "high-risk" with only a semi-commitment during Sprint Planning?

Answer 1

TL;DR

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:

1. Discard outliers, then calculate the mean. This is usually my preferred method when a story has been properly decomposed.
2. Calculate the average, including any outliers.
3. Split out contentious tasks into separate-but-dependent stories that can be estimated separately.
4. 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.

Answer 2

let's say two opinions arise. Some see this as a rather easy story (e.g. 2 points) and others foresee technical complications and judge that the story should be 20 points.

Product Owner should ask those who see this story as a 20-pointer to break this story down to 3-5 point pieces; this will help to identify the problematic spot and (if necessary) add one or more research spikes in order to clarify the situation.

Answer 3

It is a very large gap between 2 and 20 points! The OP didn't say whether the story had testable acceptance criteria listed. In my experience, that removes much of the misunderstanding about the scope of work.

The OP claims that the scope is commonly understood within the team. Then one possibility is, like Dangda pointed out, some team members may know the code base better than the others.

In either case, the prudent approach would be to schedule a one-point research story first to build a proof-of-concept. Based on the outcome, the whole team can learn something and move forward more confidently and cohesively.

Answer 4

The solution seems simple. Give the story 2 points and assign the story to one of the developers who agrees it is a 2 point story.

Generally when we have disagreements it is 2v3 or 3v5 scores. I have never seen one 2v10 or 2v20. If it is close we will generally go the score requested by the developer who will be working the story.