Developer keeps underestimating tasks time

Question

This is one of my first projects in charge, and I am leading a team of 2 dev, a senior and a mid-level one. The mid-level developer is underestimating his time on most tasks. He is telling me that the task will be finished the next day, but in the Scrum meeting, he complains that there were unforeseeable circumstances and he has to take another 2 days. I already took 5 days lee way in the project, however these are being eaten up now slowly and I am afraid I will be running over the time allocated for the project.

What should I do in this instance?

Answer 1

Hat tip to Nvoigt, Nvogel & D. Espina - all good answers, with particular emphasis on D. Espina's "sometimes, knowing one of your team is overly optimistic, you simply add your own margins to their input."

I'll just add one more frame to the question - this is a problem in risk management. The core, fundamental responsibility of the PM is to maintain stakeholder awareness of the projected delivery date (schedule), cost and quality. The behavior of this developer diminishes your confidence (adds uncertainty/risk) in your schedule. You've identified the risk.

The next step is to quantify the risk. How much impact does this have on the schedule? If you're actually working in sprints, and if the behavior creates noise in status meetings but doesn't affect the ability of the team to achieve the sprint goals, then I'd suggest a private meeting with the developer to explore the effect of this noise on the team's ability to coordinate & cooperate. If on the other hand, this dev's uncertain estimates affect either your ability to deliver sprint goals, or your teams' ability to meet your ScrumBut schedule, then this isn't a risk, it is an issue.

In that case my first step would be to quantify the risk. Track the dev's error in estimation and include that error in your schedule estimate (a healthy schedule is never a value but a range of estimates). Adjust the schedule range to ensure that the dev's behavior will fall within the projected range - that means you're going to have to track how much error there in in the dev's estimate and inflate your schedule by that amount. Work with your management to adjust their perception and to create a management reserve that can be used to compensate for the dev's estimation errors. and have the conversation with the dev about estimation errors and accuracy. The conversation is a bit different this time because the impact of the error is not to make the team's coordination harder, the impact is on the schedule and the ability to deliver. Most devs I work with don't really want that kind of visibility and would be happy to work with you to reduce the estimation error. Note that this is not a threat - this is a sincere offer to work with the dev to improve estimation. My instinct would be to explain the issue and then wait for the dev to offer some solutions. If none of the solutions are plausible, I'd suggest working with a more experienced dev to refine the estimates, including the dev in your error tracking, gamifying the estimate, etc.

Aside: I think that the other authors have covered "Do you need an accurate estimate?", but I want to draw your attention to an excellent comment by @FrankHopkins; I'll repeat it below for emphasis

many devs feel a need to be fast when management types ask for times even if you don't want to pressure at all. For them it feels easily that they are behind and they want to make that up and keep giving optimistic estimates because they tell themselves they make up their mistake to be behind (or that they were so slow last time and will be faster this time). Encourage them to double their estimations by default until they regularly overestimate and only then start to reduce their estimations again. Thy may need to clearly hear long estimates are fine.

@me22 points out another reason to stop and think about how accurate your estimate needs to be:

it can help communicating both up (to stakeholders) and down (to developers) to clarify the level of risk desired in estimates. I don't know if your project wants the "if everything goes well" estimate, the 50/50 "as likely below as above" estimate, the "if things follow long-term averages" estimate, or the "we're 99% confident in this one" estimate. They're very different values for the same task/story/epic/project.

aside: There are a wide variety of reasons for different precision in estimates, most of which will not arise in the hypothetical conversation with the dev. What should arise in the conversation with the dev is the need for the estimate to be accurate in the context in which it will be used. If the estimate is going to be used to coordinate team progress & communications, then one option is to work with the dev to understand how the job becomes harder when you don't know if/when the work that your work depends on will be complete. Most devs I know dislike sitting idly waiting for precursors to arrive.

Nothing I've suggested is a departure from the other two answers; I just wanted to frame it within the context of risk management so that it ties to another standard PM practice. (If I'm accused of just using this as an opportunity to think about and write about risk management, I'd have to plead "no contest")

Good luck.

Answer 2

In Scrum the team aims to complete the sprint goal by the end of the sprint. It shouldn't be necessary to estimate day-to-day deadlines since the delivery date is always the end of the sprint. I suggest you could stop trying to lead, stop estimating and allow the team to self-manage.

A team of three people is quite small however, and one problem may be just that your sprints are too long and therefore too ambitious so they require too much planning and co-ordination with limited resources. I would expect that with a team of three a 5-day sprint is sufficient and 10-days is probably the maximum I would want to commit to. Planning two weeks ahead with a small and busy team is always going to be challenging. Your team could consider shortening the length of a sprint.

Answer 3

Notwithstanding your approach and whether you are performing it properly, research the affects of planning fallacies. A planning fallacy is a specific form of Optimism Bias, where we have a tendency of under estimating adverse variables that could impact our performance and, therefore, we predict far favorable results than what is most likely. The bias itself is a human trait but there are other variables that cause us to under estimate project constraints, such as wanting to "please" our bosses or customers or perhaps to avoid having the project or task being eliminated if the estimates are too high.

There are estimating techniques to help defeat these tendencies, including simply asking the question about how long something might take if everything goes wrong. And sometimes, knowing one of your team is overly optimistic, you simply add your own margins to their input.

There might be Agile techniques, which perhaps you are not performing properly, that could help, too; however, I'll leave that to Agile experts to help there.

Answer 4

Joel Spolsky once wrote: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/

• The mythical perfect estimator, who exists only in your imagination, always gets every estimate exactly right. ...
• A typical bad estimator has velocities all over the map....
• Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected, because the estimate didn’t account for bug fixing, committee meetings, coffee breaks, and that crazy boss who interrupts all the time....

As estimators gain more experience, their estimating skills improve....

In the article he goes into how by knowing how "acurate" the guestimates are, that you can simulate and predict from their next guestimates the buffer needed.

Answer 5

I'd like add one more option on the table. In many cases estimation isn't really necessary. Situations when it can be useful:

1. You need to sync with other teams which depend on you
2. You need to predict the budget and decide if the project (or a feature) is worth starting

In any case, if you estimate there has to be some decision made based on the estimates. In your situation however (and it's a typical situation) what would change if the task was estimated as 5 days vs. 1 day? Would you decide not to implement it? Probably not. In which case - what was the reason for taking the effort to estimate? And then making a problem out of it, discussing it, arguing, etc.

Most of the time estimation is a waste which can be eliminated. Or at least managers can spend less energy on it. Especially in Scrum where these estimates don't matter at all.

Answer 6

do'H!

When I was a project manager I always multiplied their estimates by 4.

The workers ALWAYS are optimistic and understimate by 2x.

Upper management always wants to think they did something useful so they always compressed the project by 2x.

Result was my effort was spot on without stress or working around the clock and weekends.

Answer 7

You have to multiply programmer estimates by at least twice. A day will turn into two days. An estimate of two days will turn into four days etc.

However anybody who constantly fail your x2 estimation should not be in the team. You will need to let them go. It’s part of project management hence your job to prepare for job termination if the estimates can’t be made. Programmers need to meet deadlines no matter how much overtime or weekend to do it. Fail to do it is a sign for a new recruit.

Answer 8

Here are my thoughts regarding this,

Immediate Fix

• Find the root cause - why the developer is estimating wrong?
• Try to fix the root cause i.e. collaborate and train the developer on how to estimate correctly. [Use the other answers like 4x, 2x estimations as needed]

Long Term Fix

The idea of creating a self-organizing team.

Usually in agile, Developers are expected to work with peers [Peer Programming] i.e. One person being the reviewer or observer i.e. keeps an eye over how the project is shaping up, Points to the right direction if deviating from the track, etc. The other being the actual doer. Usually, they swap the roles as the energy levels are available.

That is how one would create a self-organizing team. With one being the observer and the rest of the team being the doer. While the roles are altered with the goal of energy optimization.

This sounds too costly so people tend to avoid it. But you have to find a way of integrating this practice into your teams. A suggested way might be, utilizing the observer to review the code or work. perform concurrently other tasks of development activities etc.

In your case, you have to take responsibility for being the observer if you know the technicalities of the job at hand. Else you should consider hiring an extra person in the future or set up the team in such a way that peer programming is possible.

Why can't one be the observer and doer at the same time? Please try it, I wish you all the very luck.

Remember it is not just about time, cost, scope, and delivering the product.

It is also about the human being at your hand, i.e.

Emotion management - Enthusiasm, Fun, Cheering, sharing pain, etc. For a human being that is what alleviates the burdens of work and lets him pursue anything.

Energy management - In terms of how much time can you be aware and conscious of the work at hand.

Knowledge management - Its obvious, When, 2 or more people sit together and try to learn or figure out a solution, they tend to learn or figure out much faster than a single person.

If one has a companion force, Then, one can leverage all the above issues easily with the other person to go very fast and far.

The job is not about making sure people do their job, it is to maintain that environment and train the people to be good companions for each other. So that they naturally enjoy and become their own executing force in long run. Usually this is one of the role of scrum master in scrum.

As far as I see it, That is how a self-organizing teams are made. Which I feel is missing in your case.