26

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?

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
TeXter
  • 425
  • 1
  • 4
  • 5
  • 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 '13 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 '13 at 16:31
  • Architect the solution. If the two pointer persists, assign it to them. – Andrew Clear Jan 14 '13 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 '13 at 17:40
  • Of course. You don't say you're assigning it to them. You challenge them to prove their solution. Or you guide the team into choosing them. Or whatever. Its the same effect. Everyone gets overly hung up on the rules, and things don't get done. Its the same as getting overly bogged down with documentation and requirements in waterfall. Accomplish the tasks, be transparent, and make sure everyone learns from the experience. – Andrew Clear Jan 14 '13 at 18:05
  • 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 '13 at 18:20
  • We told you so is a good thing when it is true, and the work environment is a good one. We told you so teaches. – Andrew Clear Jan 15 '13 at 20:06

4 Answers4

24

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.

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
  • 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 03 '14 at 16:27
7

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.

Steve V
  • 1,157
  • 1
  • 7
  • 13
2

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.

Ashok Ramachandran
  • 11,082
  • 1
  • 22
  • 50
-3

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.

Chad
  • 208
  • 1
  • 5
  • 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 '13 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. – Andrew Clear Jan 14 '13 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 '13 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 '13 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 '13 at 19:08
  • @Chad: Different teams estimate differently and therefore a point differs. There are a couple of articles here, e.g. http://pm.stackexchange.com/questions/2765/agile-why-use-points-instead-of-hours . In this particular case/team, one part of the team says: this is something that we usually did for 2 points in the past, while the other part says: no, this is different and new, will cost us "research" during development and has uncertainty, therefore it has more points. – TeXter Jan 14 '13 at 19:21
  • @TeXter - So if the one part team says they have done it before give them the task for 2 points I do not see the problem – Chad Jan 14 '13 at 19:36
  • "Because one developer may know where some code is that they can leverage to take signifigant time off of the project" - This could be a good project smell that indicates a huge lack of knowledge sharing. This could also indicate too much of cherry picking of tasks/user stories by developers resulting in concentration of knowledge on the code base. This should be avoided as much as possible. – Segers-Ian Feb 01 '15 at 19:48
  • @IanS. I suspect more likely the 10 point guy is trying to pad his score... But I was trying to put a nice spin on this. – Chad Feb 02 '15 at 05:24