For example : Some see its userstory (e.g. 2 points) and others see 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." Now the team is in deadlock condition. can you someone put some light on this. how to handle this suitation.

  • 10
    Tongue in cheek: if the team is in deadlock, lock them up in a room until they come to an unanimous decision (conclave.) They may leave the room when all surviving members vote for the same number of points. Commented Feb 24, 2020 at 11:12
  • 3
    This is pretty much an exact copy of portions of this question: pm.stackexchange.com/questions/8410/…. This question should either be duped to that one or outright deleted.
    – JeffC
    Commented Feb 24, 2020 at 23:20
  • 4
    @JeffC I agree that they are similar, but am not 100% sure they are exact duplicates. However, I’m actually a bit more concerned about the fact that it looks like part of the question was lifted from the other without linking or attribution. This should probably be brought up on meta if the community can’t handle it directly. I’d be reluctant to merge the questions without a lot more community effort put into determining whether all of the answers here would fit within the post you’ve linked to, but merging is certainly available as a moderator action if it turns out to be appropriate.
    – Todd A. Jacobs
    Commented Feb 24, 2020 at 23:49
  • 2
    @JeffC “Similar” questions are allowed, for practical and historical reasons covered in meta. The problem with nuking questions like this is that they also nuke upvoted answers, which isn’t really fair to the people who took time to answer the question. That’s why I’m suggesting you bring it up on meta; it’s definitely a situation the community should address. Meanwhile, downvotes or closing it as a duplicate doesn’t require moderator privileges; those are reserved for things the community can’t (or historically hasn’t) handled itself.
    – Todd A. Jacobs
    Commented Feb 25, 2020 at 0:49
  • 3
    @user38787 Please consider adding some unique context to your post. As it stands, this looks like unattributed plagiarism of another post (which is not allowed), and it’s hard to see how your current question differs from the other one now linked to it. As the comment thread shows, there are questions about this post which you could address through some judicious editing, and I encourage you to do that in order to make the most of your experience with the PMSE community.
    – Todd A. Jacobs
    Commented Feb 25, 2020 at 0:53

9 Answers 9


With that much variation in the estimate, it seems like the work as it's currently defined is not ready for estimation yet. Based on that wide spread in estimates, I would say that the team doesn't have a clear understanding of what is required to complete the work. Unless the work was critical and must be started and get to done as quickly as possible, I would recommend spending more time refining the work, whether that's in the portion of the team's capacity allocated to backlog refinement or planned and timeboxed in the form of a Spike.

I would expect quite a bit to come out of this additional refinement. I'd look for may include a short list of the tasks or steps needed to get the work to done and a quantification of the risks (including technical debt). Once this is done, I'd bring the work back to the team for further discussion and see if they begin to converge.

  • Breaking it down into smaller tasks seems like a good idea. Also, I might hand it to the 20 point person for a little analysis to come up with specific problems/approaches/refinements (Perhaps create a 1 point task to analyze the larger issue).
    – Bill K
    Commented Feb 25, 2020 at 19:17

The first thing you should do is encourage the team to bring concrete arguments.

"Things are more complicated than they seem" or "I don't think those complications are valid" are very vague arguments.

"I disagree, because the database-adapter has 3.000 lines of code, so changes in this class are very hard" or "Finding all methods doing X takes a long time, we should not underestimate this" are much better arguments, since you can discuss the details -> "Finding all methods doing X is easy, I know a regular expression just for that!".

Also make clear that the points are not the focus of doing the estimate, but the discussion leading to the point value! Here the knowledge gets transferred from maybe one expert to the whole team. This either shows obstacles that nobody has thought of before, or might offer shortcuts making a seemingly complex task very easy.

The Scrum Master can do several tries to get a consensus for the story points by repeating the vote, and usually after 2-3 tries this works.

If after those tries it still does not work, take the middle of the majority of the votes and take a note. After the task has been completed, you can check how good the vote was and talk with the team about it in order to learn for future estimations.

  • 5
    points are not the focus of doing the estimate but the discussion leading to the point value! This is a great "point". Points discussion uncovers so many things as it gives everyone responsibility.
    – nilan59
    Commented Feb 25, 2020 at 1:48
  • 3
    Not only responsibility but often enough the discussions uncover assumptions. Everybody thought that task X was easy / hard because of ABC. But suddenly someone remembers something or has an unusual idea which might work. Thats creativity in action.
    – hamena314
    Commented Feb 25, 2020 at 7:47

Some suggestions which could help, depending on the nature and size of the story.

  • Arrange a code walkthrough so that the team members can see the issues for themselves
  • If the story is small enough that some subset of the team are able to pick it up then maybe the team can come to an understanding that those people alone will work on this particular story and that their estimate should be used. The people who do the work can then report back on how it went.
  • If the story is big enough that a consensus is important but no consensus can be found then break it up into smaller items.
  • Don't estimate it until it is done.
  • Go with the highest estimate and plan the sprint capacity accordingly. The team can always pull additional work into the sprint if they find they have the bandwidth.

In Sprint Planning it shouldn't be the Scrum Master's role to tell the team how to accomplish the sprint goal, but it would be in order to encourage them to accept some ambiguity and inspect and adapt as they go.

  • 2
    The listed point about those doing the work making the decision is crucial. I was going to make an answer about just that until I saw it here. The person doing the work often knows best how much effort it till take them; other estimates are just back seat driving. The only frequent exception to this I've seen is when one person is very close to the thing worked on and the one working on it next does not understand the thing well, then the one historically closer sometimes has a better estimate.
    – Loduwijk
    Commented Feb 24, 2020 at 20:36
  • Upvoted for #3: Anyone estimating a story so high should usually be able to break it down into multiple smaller stories (deliverable, even if not useful to the end user yet). Commented Feb 24, 2020 at 21:37


The goal of Planning Poker is to help the team right-size the amount of work pulled into the iteration. This avoids over-committing the team, and ensures sufficient slack within an iterative process. It is not intended to deliver high precision estimates, offer an iron-clad money-back guarantee, or target higher levels of team and individual utilization within a Sprint.

Planning Poker (and Sprint Planning in general) is meant to provide a “good enough” estimate based on relative sizing, anchor-free analysis, and consensus-driven alignment. It’s simply one tool in the Scrum Master’s arsenal, and is not required by the framework. There are other estimation techniques that can be used. Even when used correctly, it can still be beneficial to complement Planning Poker with other planning and estimation techniques such as whole-Sprint confidence voting (e.g. fist-to-five), TFB/NFC/1 bucketing, or story spikes.

Different Viewpoints Add Value

A key design element of planning poker is to avoid anchoring. As a result, initial estimates can vary as widely as the perspectives and assumptions present within your team. Especially on a cross-functional teams with I-shaped people, you will often find that initial estimates vary quite widely, although they can vary with T-shaped people as well.

The goal of planning poker isn’t just to arrive at a single score. The real goal is to encourage the entire team to leverage their different experiences, perspectives, and assumptions to reach an estimate that the whole team can align with, without allowing anchoring to sideline important discussions about scope, complexity, or uncertainty that often lead to overly optimistic or pessimistic estimates.

Assigning a “Good Enough” Estimate

There are many ways to address wildly-divergent scores, each with pros and cons. A non-exhaustive list includes:

  • Discuss the reasons for the deltas, and then re-vote.
  • Average the votes to create a composite score.
  • Pick the highest score (e.g. err on the side of caution).
  • Decompose the work item (if it can be split or refactored), and then vote on the decomposed items instead.

However, the most widely-accepted approach is probably the one defined by Mike Cohn:

If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.

The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.

Within a Scrum context (and as a good rule of thumb), most teams typically time-box the discussion-and-voting process to avoid problematic user stories from becoming a time sink. A 3- or 5-minute egg timer often works well to keep discussions from going on indefinitely, and a team that can’t reach consensus after two or three rounds of voting on an item can either set the story aside (if it’s not essential to the Sprint Goal), or agree on a best guess that’s likely to be wrong but is often “good enough” when the variance is within a modest order of magnitude.

When the Team Can’t Align

In some cases, it may be necessary to replace the story with a story spike to reduce the cone of uncertainty. This technique is best applied to stories that can be deferred, so that the results of the spike can be fed back into Backlog Refinement or a future Sprint Planning session.

In the rare event that a given Product Backlog Item can’t be set aside, decomposed, or even “guesstimated,” the team can work with the Product Owner to adjust the Product Backlog, Sprint Goal, or feature to be more estimable. Remember that a key aspect of estimation is to provide confidence that work pulled into the Sprint can be completed within a single time box, and a Sprint Backlog that doesn’t garner sufficient confidence from the team that it will meet the Sprint Goal or fit within a single Sprint should be reworked or accepted as a project risk.

Story Estimates Matter Less Than Sprint-Goal Confidence

The actual estimate of any given Product/Sprint Backlog Item is often less important than the team’s overall confidence that the Sprint Goal can be met, and that the Sprint Backlog will result in a potentially-releasable increment. So, don’t get too hung up on individual estimates. It’s really the overall confidence in the Sprint Backlog that results from Sprint Planning that matters.

As an example of how to generate a confidence level for a given Sprint Backlog, you might consider the fist-to-five technique. As described in SAFe PI Planning, the team basically creates an average confidence score by voting 0-5 on their confidence that the work increment is deliverable within a single iteration. The documentation describes this key activity as follows:

[T]eams vote on their confidence in meeting their team PI objectives. Each team conducts a ‘fist of five’ vote. If the average is three fingers or above, then management should accept the commitment. If it’s less than three, the team reworks the plan. Any person voting two fingers or fewer should be given an opportunity to voice their concerns. This might add to the list of risks, require some re-planning, or simply be informative.

Even if every single user story or backlog item is 100% accurate (which almost never happens in the real world), it’s often possible to end up with a backlog that’s over-committed. Defining a confidence level for the Sprint Backlog as a whole acts as a smoothing function to balance modest variances in per-story estimates. Some stories may be over-estimated, while others are under-estimated. So long as the team has confidence that the Sprint Goal can be met and that the Sprint Backlog won’t overflow the time box of a single Sprint, the expected imprecision of Planning Poker (or any other story estimation technique) will generally get averaged out.


I like to use the 1,2,3,5,7,10,20,30,50,70,100 sequence for story points. If the team members pick neighbors, i.e. 20 and 30, just take average of 25 and move on.

If spread is higher, like 7-20 it usually means the scope of what is asked is unclear and team members are bidding on different scope, or some see difficulties others do not (either party may be right about that). This is actually a valuable thing to catch and for team to discuss.

Usually a discussion aligns team members on story point estimate - often the higher value since missing complications is more common than unknown "miracle solution". The point is that usually, if the same deliverable is being estimated and the same challenges are considered, reasonable people normally have similar estimates.

So in your case, where a discussion does not lead to similar estimates the team can agree on, I'd say you have a red flag about team interaction and / or skill. This should be your concern rather than how to size a story.

However, if team is unable to find a solution that is acceptable to everyone, one of these suggestions may resolve issue in agreeable manner for team:

  • Based on a brief presentation by the disagreeing parties to team, let the rest of team vote secretly and use average - but avoid making the "high bidder" responsible for delivering on this.
  • Ask the "low bidder" how long to do a proof of concept and revisit estimate afterwards. That ought to give information for team to make estimate.

Key is to avoid making the disagreement adversarial and to create a "winner and looser" (as far as possible).


In my scrum master training, we were taught that the team had to come to a consensus on the point values.

If the point of consternation was "If I did it it would be 2" and another person says "if I did it, it would be 20" and everybody agrees on that point, then the story gets 20 points.

Another confounding matter is the point totals above 13, wouldn't it be nice to break those up into smaller stories? So as scrum master, you can coach the team into seeing where they're talking past each other. Chances are the person who thinks it is 20 points sees an extra story or two in between the phrases "as a" and "so that I can".

If, however, the person who thinks it is 20 points does so because they know they'll have to spend two days refactoring integration tests, then they're probably right and the maverick, "I'll do it in 2" person should really just be ignored in favor of a more rigorous approach - there, I think it's up to the Product Owner to ensure that the Acceptance Criteria match with either of the two team members perceptions.


Simply put: dig until you find the deviation.

Break the task into subtasks to find where the discrepancy is; e.g.:

  • Different understanding of task scope
  • Different estimations for the same subtasks


  • Cluster estimate points, e.g. 5-10-25-50-100-200-..., to avoid single-digit discussions.

I would not recommend the top-down approach to take the mean of estimates, because:

  • It's merely solving an abstraction of the issue (how to satisfy different opinions) rather than solving the underlying discrepancy.
  • Everyone will feel overridden.
  • The discrepancy can be an indication of other issues; see above.
  • 1
    This often won't work as tasks can depend on each other. Splitting it makes individual tasks look simple but the interaction between them adds complexity. Commented Feb 27, 2020 at 9:17
  • I like this approach. Learn more about the ticket to find where the divergence is. Stating that the "interaction" between tasks is what makes it difficult strikes me as an appeal to something intangible as an excuse for not being able to estimate well.
    – Baracus
    Commented Feb 27, 2020 at 12:51

In the past, I accepted the 2, and allocated the card to the person who said it was a 2.

Usually it works out well, and honestly, don't sweat the small stuff here.

Just make sure that the person who thinks it is a 2 tells you if it is going to blow out, and if it does, get the them to pick another card, backlog it, and re estimate the card next sprint.

It's only a 2, It isn't a big deal one way or the other, your job is to make the team work, and either result will be interesting in the retro at the end of the sprint.

It doesn't have to be perfect, it COULD be that the person who is estimating it knows something everyone else doesn't, let them shine.

If they don't, then they will have learnt a thing which is useful.

  • 1
    from my experience as a SM, you can't accept anything. It is the team who should come to a consensus and tell us their point value. And if this is the case we should always try to get the highest value as well. Then worst-case scenario; committed work is done after that story blows out and best case scenario we pull more stories to the sprint in the middle of the sprint. Doing more than promised is good than overpromising and under-delivering.
    – nilan59
    Commented Feb 25, 2020 at 1:56
  • 1
    Strongly disagree with this - surely the point of Scrum is that you are a multi-skilled team working together, and who can work on anything on the board. Forcing the person that gave a ticket a low estimate to do the ticket to "prove a point" is on the edge of bullying. And what if he does a perfect implementation in a short amount of time? The high estimators look like fools. No good outcomes here.
    – Baracus
    Commented Feb 27, 2020 at 12:49
  • Op says no consensus can be had. Saying it is on the team to do so is missing the point. Commented Feb 28, 2020 at 16:18

This is one of the main flaws with Agile - estimates become deadlines. The non-technical scrum master goes for the lower estimates and suddenly the sprint is messed up. Alternatively the people who give the lower estimates are told something like "If you think it's so easy then you code it". To save face they put in a load of extra work to deliver to an estimate that they don't want to admit was wrong. When this starts happening every sprint people lose hope, quit and look for a job where they don't use agile. My advice is to go with the longest estimates. You can add more work to the sprint later if items finish early. Estimates from your staff that have previously provided accurate estimates should carry more weight. If a task early in the sprint has too short an estimate then then theme of every meeting will be "we are behind schedule" and again your staff will be looking for a better job.

  • 1
    It's still miles better than deadlines that come from outside the dev team, such as sales targets. The 'low-estimators' have a chance to learn, and the scrum master has a chance to recognise regular low-estimators. Most importantly, the 'death-march' resulting from a low estimate only lasts one sprint. I agree with your advice though. Commented Feb 27, 2020 at 13:11
  • 1
    @Robin The 'death-march' only lasts one sprint if it is recognized and the same mistake is not repeated. Otherwise it's every sprint. I suggest that this is more likely with a non-technical scrum master who is focused on trying to improve velocity. I agree that outside deadlines are worse. The dream of Agile is to not have deadlines but to be able to release what parts of the software are finished at any time. Commented Feb 27, 2020 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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