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

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

Introduction

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.

Answer 5

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).

Answer 6

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.

Answer 7

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

Generally:

• 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.

Answer 8

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.

Answer 9

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.