I have two kinds of projects:

  • Agile where estimates made with story points using planning poker http://www.planitpoker.com/

  • Waterfall/Kanban where estimates made on hours/days divided to specialty. Like FE/BE/QA/DevOps/Designer/PM e.t.c.

The problem is that a few developers don't want to give any estimates using either method. Neither personal time estimates nor depersonalized relative story points. Sometimes there are even tantrums around estimating or they take sick leave on planning day. If I have several of devs they will wait until senior devs provide estimates on their own. QAs don't want to participate at all despite the fact they are developers too in all meanings.

What I have tried:

  1. Give them time to check stories and specs
  2. Let them investigate issue with hands-on code
  3. Customer and PO always on planning meetings to answer all questions
  4. Each story has use cases, mock ups, scribbles, designs
  5. Every story decomposed to minimum valuable size when Agile or not less than 4 hours not more than 8 hours when Waterfall
  6. There is no personal responsibility for estimates or penalty/blaming for underestimating

What techniques exist to alleviate this problem? What more can I try?

  • 1
    How were they introduced to agile? Do they even understand what agile is? It can be hard to get developers to provide estimates instead of just jumping into code if they don't understand why. Make sure they know why you're asking them for this, how to prepare useful estimates, and how it will make their lives easier (not just so you can put something in your tracking spreadsheet). Their buy-in is essential. If you've done all of the above and they still don't cooperate, either look for another methodology or escalate.
    – Pedro
    Jan 27, 2016 at 12:12
  • Hire professionals next time. Giving an estimate is part of the job, agile or not. Would you hire developers that refuse testing or committing their code? Estimates might be wrong, maybe even for a good reason, but refusing to give one without reasons is ground for termination.
    – nvoigt
    Jan 27, 2016 at 14:29
  • @Pedro yep, they all working agile for years. Problems not in a methodology, as you can see we use Scrum with storypoints and Kanban with ideal time estimates. Jan 28, 2016 at 10:06
  • 5
    @AlexanderAverchenko Right now, they are not highly skilled. Not giving an estimate without pointing out a way to do it in the future (like saying "to provide an estimate, I need xy") is just... it's not even unprofessional, it's refusing to do their work. That's their damn job. I fail to see how you can call someone a "good developer" that openly refuses to do his job. Typing code does not make a good developer, that would only make for a good code monkey. There is more to developing software than just code. And your "developers" fail at their job.
    – nvoigt
    Jan 28, 2016 at 10:15
  • 1
    "If you're not willing to cooperate in the process, that makes my job easier. I'll simply tell upper management to hold you accountable to randomly determined durations." Of course you've just said that management has no intention of holding anyone accountable "won't give me candy for throwing good developers off the boat". The problem isn't the developers - the problem is that your management is holding you accountable, but are unwilling to participate in the process.
    – MCW
    Nov 1, 2021 at 13:21

9 Answers 9


Some times there is even tantrums around estimating or they are taking sick leaves on planing day.

These are grown-ups we are talking about? Maybe you should ask them directly what the issue with estimations are. I think maybe they don't want to be accountable for when they do not meet expectation, is this true? People cannot work harder then they can. This is also a good reason to use relative sizes.

Question yourself why and how you are going to use the estimations and communicate this honestly with the developers. I think the goal should be to get a forecast, but more important to get the discussion going to make tasks smaller, simpler and to create a common ground on what the tasks consists of.

To make estimations easier, maybe use a fixed relative scale that everyone can relate to. I have come across "The abstract weight of smart use cases" as used by Smart (described in the book This is Agile) and used in this slide-share.

Abstract weight of smart use cases

1: Piece of cake

2: Moderate

3: Average

4: Hard

5: Very difficult

8: Extreme, but known

10: Extreme and unknown

I think estimations on a scale like this is easier to grasp then relative story points. Still let everyone vote blinded and let them turn up the complexity at the same time, this to prevent them influencing each other. Then discuss if the estimates are not close together, else just average.

  • Yep, grown-ups, but talented developers often have some "particular qualities". Thanks for the scale i will try it next week. Jan 28, 2016 at 9:46

This issue is not just limited to developers or agile or even in the IT industry. This cuts across all industries and all types of roles.

Providing estimates is about trying to predict the future as accurately and precisely as we can and the inconvenient truth is we have no ability to predict the future with any real degree of accuracy or precision.

The human condition, however, expects 100% accuracy and precision and anything less is broken and unusable. We expect definitive results and believe we actually have control over the future. In fact, our world is hugely probabilistic, unreliable, unpredictable, and very random. But that does not sell, customers don't buy that, and when you bring up statistics everyone's eyes glaze over.

The issue is getting estimates is the culture in which those estimates are made. It's the expectation of 100% accuracy and precision and the severe consequences we have when we don't achieve that, assuming the team failed versus just a random result within the normal distribution of possible results. Collectively, we have successfully selected out estimating behavior from our behavior repertoire by rewarding the wrong things and punishing the right things.

If you want to change this behavior, you need to change the cultural dynamic. Good luck with that.

  • No there is no pressure for not fitting into estimates. We are extremely loyal for developer mistakes. However i find your point about improving culture very interesting. Maybe you can suggest something to read about it? Jan 28, 2016 at 9:53
  • 6
    "...mistakes." The culture about which I wrote is very, very ingrained in the human condition. Your comment shows this. Jan 28, 2016 at 11:22

Have you tried teaching them how to make estimates? I didn't see that in your list, and not everyone automatically "gets" how to do it.

I've encountered two main reasons for an unwillingness to make estimates: one was anxiety over being held to it, but the other was that they'd never done it before, so when I asked them "how long do you think that will take?" they answered honestly "I have no idea." When I pressed them, they said "Well I would just be guessing!" (Which might translate, in planning poker, to picking a card at random.)

So we talked about how an estimate is a guess, but it's an educated guess, and everybody understands that; and then I walked them roughly through the mental process I use to make estimates, and said of course they wouldn't be very good at it at first if they'd never done it before, but we would practice and they would get better at it. I also contextualized why estimates were important for us as a team to be able to do (building confidence in ourselves and trust with our stakeholders that we will be able to do what we say we will be able to do), and pointed out that learning to make estimates is also a good career development move. (If the folks who are resistant are deferring to "senior devs", this may be a good argument for them.)

I think the easiest way for people to start making estimates is in terms of ideal work days, ie, supposing that I could spend 100% of my time on this task without interruption, how long would it take me? Story points may be too abstract for people who are just learning this skill.

Re your QA people: I've also found that people are reluctant to participate in estimating tasks that they won't directly work on, eg people who work on one subsystem don't want to estimate work that is contained entirely within another subsystem. My solution has been to say "well you've seen how long it takes the other subsystem folks to do tasks like that, so give it your best guess that way." They're still reluctant, but at least I've given them a rubric to follow.

At this point I don't think there's anything left for you to do in the team process. I would try one or more of the following (in no particular order):

  • approach each reluctant dev individually in private, and ask from a position of curiosity, what is the issue they have with making estimates?

  • approach the reluctant devs' line managers (assuming that's not you?), and give feedback that they apparently need training in how to make estimates. (IE, don't get into "won't" and tantrums; focus on "don't seem to be able to do that task", therefore must need training)

  • approach the line managers, and make sure your expectations of dev responsibilities is consistent with theirs, esp. around estimation.


I have found that developers are nervous about providing estimates (we have renamed them guesstimates) because they are afraid that they will be held to account if they underestimate / overestimate. This creates uncertainty, fear and apprehension.

I have found more recently that planning poker helps the team decide and I have got good estimates from this. Have you tried this? https://www.mountaingoatsoftware.com/agile/planning-poker

It's like playing a game of cards and it can be fun. I have also explained to the team why we need estimates (an that is all they are - estimates) and why it is better for them to overestimate rather than underestimate. They need to be able to give an estimate that they are comfortable with. I agree with David Espina here. Make estimation fun. Change it for the better.

  • Thanks we already using that. And it is still stressfull for some developers. Jan 28, 2016 at 9:38
  • Are you sure? "If i have several of dev's they will wait until senior dev's shall provide estimates on his own." because this sentence says you don't. Since with planning poker everyone gives their estimate at the SAME time, the page reads: "When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.". Jan 28, 2016 at 12:59
  • @Niels van Reijmersdal Hundred percent sure. We are using planitpoker.com they just provide random estimate for the 1 round and then just use the same card as Senior spec on the next round after discussion. Jan 28, 2016 at 13:06
  • @AlexanderAverchenko OMG!, I feel sorry for you! ;-) Maybe its a cultural issue out of respect of the more seniors? I remember when working with teams in Bulgaria that we also had a harder time during the estimation sessions. Jan 28, 2016 at 13:14
  • I book a meeting room and arrange the team around the table and we use good old-fashioned cards because I have found with software you don't get the same effect. I abandoned the software in favour of team discussion and the non-verbal cues when all cards are revealed. I have also asked why estimates are so different if there are really high and low ones revealed at the same time. I find this works. Give it a go :)
    – Treasa
    Jan 28, 2016 at 20:12

Interesting that the answers are about the team not either following the process or needing trained. There is a movement in Agile around #noestimates, as there is a feeling that even using story points is rooted in old school PM estimation.

If you are using INVEST in your stories (Independent, Negotiable, Valuable, Estimable, Small and Testable) think about what you put into the story, now the idea here is to build stories of a similar size. You can then use your metrics to calculate average time to complete, and use that rather than velocity (or task hours) in planning.

Look at the work Alan Holub is doing. At the end of the day, it works out as accurate as trying to estimate, we'd and doesn't need a 10% commitment from the team.


Everything you are doing already, that you have listed above, are excellent and while there are a few more things you can do, there isn't too much before you take it up the chain. Somethings that are worth doing:

  1. Having Agile trainings. Studies show that the better a team is versed in agile, the more they will embrace it and the better a team they become.

  2. Partner with your lead developer in solving this problem. Sometimes, when a scrum master cannot seem to get through to junior dev, the lead developer can. Working with your lead dev on developing a team culture that is open to estimation.

Unfortunately, if neither of these things work you may need to address their behavior with their managers or with HR. Personally, if I had a team member that threw a tantrum, I would not let it go. Not only is it unprofessional, but it sets a bad example for the team and if you let him get away with it he will learn that it is an acceptable and effective way to get out of estimating.

That is a last resort though!


First off; when the team reaches the business targets; don't worry about it.


When I read the comments about working for years with Agile methodology I suspect that you are only partially implementing it. Without sprint planning, you are not using Agile.

This would be a good one to tackle on the retrospectives; as the process clearly would benefit from it. When planning is continuously on the low side: that's also something you should handle in the retrospective.

  • Who said anything about Scrum? I see Agile mentioned. I see waterfall and Kanban mentioned, but no where do I see the word "scrum".
    – RubberDuck
    Jan 31, 2016 at 14:35
  • I did see : Storypoints, Planning poker; so I assumed Scrum; will edit to Agile
    – acidjunk
    Feb 1, 2016 at 9:52

From the perspective of a dev, emitting an estimate invites the following probability distribution over outcomes:

  • 50% chance to overshoot thus not only having to take up more tasks but also people seeing you as lazy
  • 50% chance to undershoot thus be done late and get yelled at by the manager
  • 0% chance to have estimated correctly
  • 100% chance to spend time on a task from which the dev effort is not directly helped

So in order to abolish coding and proceed to estimating, a carrot or stick is needed.

Spoken from the perspective of 4 agile workplaces IMHO none of which worked well. One was a leading German car manufacturer. Another was a Silicon Valley ... company.


You might consider not doing estimation at all but using forecasting instead, without estimates. For example, see Create Faster and More Accurate Forecasts using Probabilities

Your process needs to meet some conditions (such as controlling WIP and rightsizing of tasks/stories) but it might be worth it. One benefit is that you don't have to press the developers to give estimates.

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.