Developers don't like to estimate. What can I do to improve the process?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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!

Answer 7

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

BUT

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.

Answer 8

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

Answer 9

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.