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?

  • I'd like to note that this is not a Scrum-only problem. Disagreements on difficulty of implementation can be a difficult subject under any methodology.
    – MrFox
    Jan 14, 2013 at 16:03
  • We usually solved this by giving the person that said they could do it for 2 points the story.
    – Chad
    Jan 14, 2013 at 16:31
  • Architect the solution. If the two pointer persists, assign it to them. Jan 14, 2013 at 17:31
  • 2
    @aclear16 The Scrum Master does not assign work to individual team members. The successful Scrum Master coaches the team to be self-organizing.
    – Todd A. Jacobs
    Jan 14, 2013 at 17:40
  • 1
    See also one of the answers below. "Well, lowest bidder prove it!" does not seem to me as a good approach. Also, this automatically will bind a user story to a certain team member, who might be blamed in the end ("We told you so!").
    – TeXter
    Jan 14, 2013 at 18:20

4 Answers 4



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.

  • 2
    This is a good answer, however I would like to add another solution for uncertainty - have a spike or some investigation to answer the specific question causing the uncertainty. This might mean an hour can sway the team to agree on either the '2' or the '20'.
    – SpoonerNZ
    Nov 3, 2014 at 16:27

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.

  • 1
    Great answer--although hopefully anyone on the team could do this as well, not just the product owner. Jan 25, 2014 at 22:03

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.


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.

  • 3
    How would assigning a potentially mis-estimated story to a specific individual help with the core Scrum tenet of "succeed or fail as a team?" This seems like a project smell; it's just a proxy for holding individuals accountable for a team process.
    – Todd A. Jacobs
    Jan 14, 2013 at 17:28
  • @Gnome: No. Either the estimator was correct, in which case he can explain why he/she was correct at the retrospective and increase the team knowledge, or they were wrong and they will learn why and be better the next time around. Improving individuals is a large part of improving a team. Jan 14, 2013 at 17:32
  • @CodeGnome - Because one developer may know where some code is that they can leverage to take signifigant time off of the project. But unless you already understand that code there is going to be some time spent learning it so they can make the changes. It is possible that someone who already knows that code base could do something in 2 days that would take 3 - 4 weeks for someone who does not.
    – Chad
    Jan 14, 2013 at 17:54
  • During Estimation, the team should estimate functionality, not implementation effort. So the 2 points are two points of features, not 2 points of workload. This, plus the fact that the SM does not assign tasks does not make this direction sound correct for me.
    – TeXter
    Jan 14, 2013 at 18:16
  • @TeXter - So you are saying the team is debating how important the feature is not how much effort it will take to develop?
    – Chad
    Jan 14, 2013 at 19:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.