In an ideal world using Scrum we are all supposed to take part in the iteration planning, select tasks and stories, from the groomed backlog. You then have a planning meeting where everyone comes together and agrees on estimates.

In the real world, or at least where I work we do the pull most of the work from the backlog and have iteration planning, and using planning poker come up with fairly consistent estimates, or at least estimates we can agree on.

However the exception to this for us is our SQA resource, who overestimates everything. He does get some extra work from other people that he is the only "qualified" person to estimate, but on odd occasion where someone else has had to do the work, it is completed in a fraction of the time estimated. This would be fine(or at least I'd be ok with it) if these tasks were all finished ahead of schedule, but these estimates seem to be used as more of a "This is how much time I have to do this, and once I am finished, I can spend the rest of the time dozing"!

When challenged on any of the estimates, lists of reasons are produced that explain why they will take the estimate, but they all boil down to: "This is how long it will take me."

So in a methodology where buy in is so important how do I get these estimates more realistic. I am the scrum master on the team, but have no direct authority over this resource. (i.e. I'm not his team lead.)

  • 3
    I'm not sure this is a "how to do scrum" question, but more of a person "gaming the system" to get out of work.
    – Jeff O
    Commented Jan 14, 2013 at 13:54
  • 2
    Can I check that you are running a '2-estimation' version of scrum? Because if you are not, and you are using only the 'story point' estimation, then the entire team should be doing the estimation, not the individual given the task. Commented Jan 14, 2013 at 15:52
  • 1
    possible duplicate of How should a team handle disagreements about story-point estimates in Scrum?
    – Todd A. Jacobs
    Commented Jan 14, 2013 at 17:49
  • 4
    Why is his 'overestimating' a problem? Commented Jan 15, 2013 at 1:08
  • 4
    It sounds like the problem is not his overestimating, but that he is under-performing/not contributing at the level you believe he should be (and the overestimating is how he games the system to make it possible). Would that be a fair characterization of the underlying problem? Commented Jan 15, 2013 at 11:56

9 Answers 9


I'm going to assume that you are running one of the versions of Scrum in which there is both a "story point" estimation, done by the entire team, and an "hours estimation" done by the individual assigned the work. If it's not, and your only estimation is the story point one, this issue shouldn't arise because the estimation should be done by concensus of the entire team. Your problem member shouldn't be able to override their input.

In a very real sense, as scrummaster without managerial authority, this isn't strictly your problem. Scrummaster is a facilitator, and your job is to help the team do their job as well as possible using the people you have. However I'll assume you want to do the best for your team, and there may be some things you can do. However given you have no authority you're going to have to get the team to sort the issue out.

The first thing you can do is draw attention to it. If this person is consistently making hour estimates for his tasks that are higher than the hour estimates for other tasks with similar number of story points, then I would draw this to the attention of the team at the next planning meeting or retrospective, and get the person's input. It may be that the team is consistently underestimating the difficulty of tasks in his area of expertize, but at least give the team a chance to sort it out. There may be some peer pressure for this guy to shape up if the rest of the team think he is slacking.

Finally, if you are sure this is an issue, and the team doesn't sort it out, bring your concerns to his manager. If you are invited to give feedback as part of a formal performance review, use that opportunity. If not, approach him anyway.

  • Brining peer pressure to bear would be an ideal solution, I'm not sure if I can manage to do it without coming across vindictive and argumentative. :(
    – user7192
    Commented Jan 14, 2013 at 16:01
  • Just point out the issue and ask the question. Don't presume an answer. Phrase it as a desire to get estimation right. See what the other team members say. Commented Jan 14, 2013 at 16:28
  • 1
    If you do bring the issue, I'd suggest not to do it during a meeting when everybody else is there. That might make the person defensive and then you won't get much out of the discussion.
    – laurent
    Commented Jan 15, 2013 at 3:13
  • The point of bringing it up at the meeting is to get the rest of the team engaged. If they also feel the problem guy is underperforming they are more likely to be able to pressure him into shaping up. It would be different if the poster was the problem guy's boss. Commented Jan 15, 2013 at 14:11


Personality conflicts and process diseconomies are clouding the real issue. Tracking the proper performance metrics will improve your overall process and provide guidance for addressing issues of team composition.

Your Problem Isn't Estimates

[O]ur SQA resource...overestimates everything.

So what? If your team is using planning poker, or any other commonly-used tool for building consensus estimates, then this person's estimates are simply outliers. See How should a team handle disagreements about story-point estimates in Scrum? for various ways to deal with this issue.

Estimates are not commitments, and velocity is just another estimating tool, not an end unto itself. As a result, the Scrum Master should encourage the whole team to estimate the task as accurately as possible during Sprint Planning, and then move on.

What Estimates Are Really For

In the end, though, this has nothing to do with estimation. Scrum estimates are "educated guesses" about the level of effort required to do something. The value of estimates lie in in the confidence interval your team is able to assign to estimation-accuracy over time.

Estimates are explicitly not management targets, and neither is velocity. If you're using them this way, you will not achieve your team objectives.

Some of the Problems Are Personality-Based

"This is how much time I have to do this, and once I am finished, I can spend the rest of the time dozing!"

This is speculation on your part; you are imputing motives. It indicates that you have an adversarial relationship with this person, and you need to own 50% of that.

If you set aside your personality issues with this person, your underlying concern seems to be that you think this person is lazy, not pulling his weight, or not meeting your expectations for efficiency. However, planning poker (or other estimation tools) will not help you address any of these concerns.

Your Solutions Should Focus on Performance-Based Process Improvements

Once you accept that your issue is not the estimates, but in your perception that this person is not performing adequately (for whatever value of "adequate" you care to apply), then you will free yourself to address performance concerns without clouding the issue.

[Our process] allows him to do so little work that the other team members need to end up doing work that he should have completed as part of the over all release, so instead of being able to pull extra development features off the back log they/we end up doing sqa stories.

Your process needs improvement. Whether the person is actually a bottleneck or not, if the process doesn't enable you to refactor your work-flow or adjust resources to remove resource constraints then your process is broken.

For example, if all SQA work flows through this one person, this may not be an optimal process for your team regardless of who fills that role. If the person performing SQA work isn't able to deliver sufficient value within each Sprint, you can do any of the following:

  • Limit work-in-progress (WIP) until the capacity of your process is not saturated.
  • Add additional capacity to your process. Examples might include adding more SQA resources or replacing inefficient personnel with more productive team members.
  • Adjust project delivery dates to align with actual throughput instead of management-defined targets.
  • Refactor your organization's hiring, compensation, performance review, and retention processes to improve the quality of your team members.

Improving your process will help you accurately measure and manage team member performance. At the end of the day, whether a person's performance adds or subtracts value from the team is what counts, and that's what you should be focused on.

  • Interesting points.
    – user7192
    Commented Jan 15, 2013 at 12:39

Break tasks into smaller details.

When this individual gives you an outrageous estimate ask them more details about it. For example, if the task is to Test Feature X, it might involve setting up environment Y, going through cases Z, etc. Then ask them to estimate on each sub-point. You will be able to drill down and ask things like "Does it really take 2 days to set up the testing environment?". Frequently you'll get "Oh well perhaps not, probably I can do that in one afternoon." You can also say "John went through test cases Z in this much time, what has changed?", and the answer will frequently be "Uhh nothing, I guess we CAN do it in that much time".

Estimate difficulty, not time.

It sounds like you are running an agile environment. In that case, you shouldn't be estimating man-hours but rather difficulty points, and then gauging team velocity. This will make it harder for this person to 'pad' because

1) Velocity will catch up with "point inflation". If they like to give themselves 2 hours for every 1 hour of real work, then in a few sprints 20 points will equal 10 today's points. It will be hard for them to continuously infate with a straight face.

2) You will able to objectively say "Jane gets twice as much done as John. What's the dealio, John?"

If they're really lazy and never want to work...

Then you have a culture problem that you need to solve. They could be de-motivated for different reasons (pay, boring work, lack of direction). They could also be the one bad apple that should be let go. We'd need more information to answer this one.

  • "Estimate difficulty not time". In many implementations of Scrum there are two stages of estimation. "Story point" estimation should be based on difficulty, but it is also done by the entire team, not the individual, so I am assuming that is not what the questioner is talking about. There is frequently a second estimation, done by the individual carrying out the task, which should be in hours. I assume that is what the questioner is talking about. Commented Jan 14, 2013 at 15:37
  • It's a bit of both really, he'll haggle outrageously in the meetings, always looking for the most amount of hours that he can get
    – user7192
    Commented Jan 14, 2013 at 15:39
  • Some good suggestions there, I like the idea of Velocity and the breaking down of stuff. More work for me, as even to ask him to break it down more would have him complaining that it's unnecessary extra work!
    – user7192
    Commented Jan 14, 2013 at 15:41
  • @DJClayworth The OP does not mention anything about implementing Scrum in the way you describe. Furthermore, that kind of an implementation seems a bit broken to me because it establishes a direct link between points and time (a relationship that should be derived from velocity/past experience, not estimated directly!).
    – MrFox
    Commented Jan 14, 2013 at 15:49
  • 1
    The only concern I have with this approach is that the manager could "pressure" the employee into giving an estimate that he/she isn't capable of meeting. Plus, I don't think comparing the employee to "John" is a good idea as it could create animosity, lowering the cohesiveness of the team.
    – jmort253
    Commented Jan 15, 2013 at 3:55

Development is not assembly line work. Some developers take quite a bit longer to develop code than others. It is possible that your developer is, while competent, one who takes longer to develop than others. Unless you are his manager, if he is goofing off or not should not be your concern. Rather you should be concerned that he is meeting resource needs of your team.

Instead of allowing him to poker his how stories let the team help set the score for the stories. Your SQA Resource should be able to explain briefly what will need to be done and the team should be able to reasonably score it. It may take him 2 or 3 days to do a 1 point task but he will only get credit for the 1 point.

If the SQA developer is not taking on enough points or not able to fulfill his commitment then you can contact the SQA team and ask for additional resources explaining that your team member is not able to meet all of your SQA needs. After a few iterations you should have plenty of data to back this up.

The important thing here is to remember to manage the work not the people.

  • I don't understand what you mean by: "Rather you should be concerned that he is meeting resource needs of your team."
    – user7192
    Commented Jan 14, 2013 at 15:51
  • It's of concern to me because it becomes a bottle neck for my team. and means I frequently end up parcelling up his work and assigning it to other people just to get it done on time. :(
    – user7192
    Commented Jan 14, 2013 at 15:54
  • 1
    @user7192 - That is the point here. You should be able to show that your SQA resource is only able to work at a velocity of 5 when you need 10-12 points of velocity from SQA Resource. Your problem is not the developer but rather the quantity of work being completed. If you have a resource that is only completing 5 points you can provide that metric to the manager and explain that you need 10-12 (or what ever your scale is) of velocity from your SQA Resources.
    – Chad
    Commented Jan 14, 2013 at 16:20

There are several approaches to this.

One way, is to change his incentive, so he is rewarded by delivering quickly - either by official time to work on his pet project, salary or what ever motivates him.

Another way is to remove his status as authority, by redirecting this work elsewhere. As you say some times this has happened, and been completed much quicker, it makes commercial sense to do this more often. The times it doesn't succeed, the original employee provides training to the person tasked with the work and is not allowed to take control of the task directly.
Over time, he will have to either change his estimates, or will become irrelevant.

The third way is to implement monitoring of his computer usage. If he is not working actively on the task, it will show up on his computer usage. Several days of web surfing is plenty of evidence for company disciplinary action, and my guess is he will change employers if it becomes too much work here.

  • 1
    I really disagree with the computer usage monitoring. Firstly it creates additional PM or management overhead because you need to review it. Secondly usage doesn't really tell you anything about productivity. I could sit all day with Visual Studio open in front of me without ever getting any useful work done. You need to find the more fundamental cause of this problem.
    – Willl
    Commented Jan 14, 2013 at 14:28
  • Each of these approaches would achieve different results. The computer monitoring approach would be a way to move this unproductive and fairly arrogant developer onto a different company. Commented Jan 14, 2013 at 15:20
  • I don't like the second approach, it would give him exactly what he wants, he would have less and less work to do, and the rest of the team would end up doing his work for him. I'm not sure what you mean by becoming irrelevant. However +1 the usage monitoring is an interesting idea.
    – user7192
    Commented Jan 14, 2013 at 15:44
  • 1
    At the moment, he is probably abusing his position of knowledge, what we would be doing would be to undermine his role as being that single source. In the short term, he would be doing work that anyone could do, and he has little room to inflate the time scale. In the longer term, others can do the "specialist" work, and again his ability to inflate the time scales has gone, as well as his power to dictate. Commented Jan 14, 2013 at 16:40
  • @Ptolemy I see what you mean now, I have indeed started taking some steps in this direction. Getting other people, myself included to do some of his more regular tasks, so that when he says, this will take 9hours, we can say it only took us 3 when we were doing it!
    – user7192
    Commented Jan 15, 2013 at 8:00

The first thing to determine is whether or not this is really a problem. If someone delivers on time according to the estimates that you have based your plan on then you don't have much of an issue in the context of your project.

Let's assume that your SQA delivers on time most of the time. That means that for some reason his estimates are reasonably accurate. If it isn't your role to dig up the root cause for why he takes longer than anyone else and it doesn't affect your projects then you really don't have a problem. If it is your role and/or your projects are affected take the time to find out what the root causes are in a non-confrontational manner.

If your projects are affected but you have no influence on the SQA your best short-term fix may be to consistently request other SQAs be assigned to your projects.

  • I've put some comments against some of the answer, that I think address some of your points, especially on the accuracy of his estimates. As to how it effects the project, he's too busy to do improvement work, documents that he should be updating, are pushed to the backlog, the bare minimum is done to survive week to week, no enhancements or improvements.
    – user7192
    Commented Jan 14, 2013 at 15:59

Whatever you do, do not make estimation a political process. You can't get accurate estimates if people don't want to give them to you, period. Fighting the one team member over them risks compromising the accuracy of the other estimates, and then you lose really valuable information.

The actual issue is that it appears that the guy is incredibly slow. You suspect it's because he won't do more, rather than that he can't, but either way, you think he isn't pulling his weight (and actually it sounds pretty convincing that he isn't).

First, do what you can to verify that he really isn't productive. Make sure he isn't spending his time on productive things that don't produce story points directly, like helping others with their work, or doing other projects entirely. It doesn't sound like this is the case, but do your due diligence.

Then, you either have to fix the problem or at least tell whoever you report to that this guy isn't as productive as you expected, and let them deal with it. It's hard to advice on this, because it's very much about personalities and personal relationships.

But don't make it about estimates, per se. In fact on the bright side, it sounds like he does a good job of estimating his own poor productivity.


Estimates are just that - estimates. And they're supposed to be challenged. That's how a manager gets a "confidence level" in what's going on, by listening and challenging until there is agreement and buy-in.

So challenge him. If he gives the same argument, then challenge it - ask why others were able to do it faster.

But as others have said - don't make it adversarial or political, and don't assume you're 'right'. Maybe he does have some good reasons that you're unaware of.

So challenge, but listen.


The concept of a "realistic" estimate is a nebulous one. A realistic estimate is not a single number, but rather a range...an in many cases quite a broad range. Where you target is solely based on one's interpretation of risk banged against one's risk appetite. And because work is probabilistic under many random variables, the fact you have a couple of times when work performed by another came in less than what this guy predicted does not prove anything.

So I would get rid of this notion of a "realistic" estimate because no one has the capability of predicting the future to arrive at an estimate that ends up truly realistic. Instead, focus your energy on the risk management part of estimating. Do not build single point estimates but build a range. Identify what threats exist that could cause you to end up on the outside of that range and what opportunities exist that could help you bring it in.

And finally, separate the function of estimating and targeting. There are two different roles that play in this. The experts who do the work provide the estimates, but the business people responsible for delivery provide the targets.

  • While I understand that estimates may not always be realistic, and have quite a broad range, I still believe that it is possible for someone to be outside of the acceptable range, for example if if he says something takes 6hours, and I do it in 35 minutes. He's the expert in the field, and I'm a novice! or If he says something will take 20 man days, I give it to 3 different people in parts and it's done in 3.5 man days that to me would seem like overestimation
    – user7192
    Commented Jan 14, 2013 at 15:50
  • That can certainly be true. He could definitely be an extreme. But, I don't know how that could be firmly substantiated if organizations do not conduct probabilistic estimating on an ongoing basis, where good risk management is a true part of it. In my experience, that is very very rare. So that's the basis of my answer. Commented Jan 14, 2013 at 15:58

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.