3 ms·

It's surprising that developers and business people still haven't found a way to come together on this stuff and explain to each other why our views on estimate

It's surprising that developers and business people still haven't found a way to come together on this stuff and explain to each other why our views on estimates don't line up. At the end of the day a business is always going to need some sort of idea of what's being built and when it might be ready so that they can get a rough schedule together. No matter what games developers and project managers play with story points, or t-shirt sizes, or the myriad of other coping strategies they come up with, someone in the chain is going to try and map those to time scales. In my experience, a reasonably senior developer can give a rough estimate of how long something is going to take in any case that isn't a complete unknown, if they really can't then you need an investigation project and that can be given a set time. But for almost everything else you can roughly say if it's an hour, or a day, or a week, or month. As long as everyone accepts that sometimes that will be over, and sometime under. If its an hour that doesn't mean you can do eight of them in a work day, but it means you can prioritise work. That's the key I think, if you have a fixed date or a fairly fixed date, then it's often a good constraint. What you need to do is prioritise the work, and the only way you can do that is if you know that the things in your list could reasonably be done in that time. You can't have no estimates, and task three means your entire team needs to invent an AI or something stupid that will burn the whole timeline down. If you've put a rough estimate of a week on something and you're reaching the end of week two, it's a great time to reassess. What technical people often don't get told, or don't understand is that sometimes something is only valuable if it can be done in a certain time. The business might want a feature that could be done in a week, but have no interest in it if it'll take six months. If both sides can admit to their fears then it shouldn't really be too complex. Business is scared you'll get to the deadline and have 20% of the work done, with a good prioritised list they'll probably be happy if you're 80% of the way there. Developers are scared you'll hold it over them and berate them if their one day estimate becomes two days, but they probably know their one week estimate is bullshit and they just want to cover their ass a bit.

neurotrace 5y ago
So incredibly true. I used to be staunchly in the "estimates are empty promises made by business people" camp. The last couple of years I've worked in an environment where both engineering and product understand that estimates are not created out of thin air and they have real consequences on both sides of the coin. Our estimates have become far more accurate not only because we all understand that they _are_ estimates but because engineering is able to creatively come up with solutions that meet the business needs, not just the outlined "requirements." Most importantly, any potential shifts in our estimates are communicated every week and we have built in float time to account for these shifts. We haven't missed an estimated date in over a year.

neurotrace 5y ago

So incredibly true. I used to be staunchly in the "estimates are empty promises made by business people" camp. The last couple of years I've worked in an environment where both engineering and product understand that estimates are not created out of thin air and they have real consequences on both sides of the coin. Our estimates have become far more accurate not only because we all understand that they _are_ estimates but because engineering is able to creatively come up with solutions that meet the business needs, not just the outlined "requirements." Most importantly, any potential shifts in our estimates are communicated every week and we have built in float time to account for these shifts. We haven't missed an estimated date in over a year.