How to deal with a team member who constantly overestimates

Question

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

Answer 1

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.

Answer 2

TL; DR

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.