Programming Estimation: Estimate Software Tasks With Caution

When someone comes to you for an estimate of a software task, do you feel uneasy?
Incorrect estimates can be one of the biggest sources of stress for software developers.
In this video, I share some tips that will help you have better success rates when estimating software.
Though you may not be able to get out of estimating altogether (#noestimates), you can minimize the damage.
Subscribe for more videos about Healthy Software Development: kzbin.info...
Related Videos:
"Software Estimation: Trading Effort For Outcomes": • Estimate Software - Tr...
"Agile Project Management: Is It Stopping You From Being Agile?": • Agile Project Manageme...
"How To Say "No" To Software Project Requests:
• Say NO On A Software P...
#programming #career #estimation

[@HealthyDev]

How have you dealt with demands for estimates that you know you can't commit to on software projects? Leave me your thoughts below. Thanks!

[@bensonkayden9346]

@Korbyn Avi Meh I watch on flixportal. You can find it thru google :) -benson

[@KapnKregg]

At one of my first jobs, the product owner - who had never developed software before - would do all of the ticket estimation. They wouldn't allow developer input on how long development was going to take because the estimates always seemed to be too large in management's opinion. They are now out of business.

[@HealthyDev]

Wow, yeah that sounds about right. “We don’t like reality so we’ll just have someone commit who’s willing to lie. Then reality will bend to our will.”

[@JakeBastlerZ]

Another great video! Every newbie needs to see this to not get sucked into that anxiety spiral of "give me an estimate, now we're overdue and it's your fault"

[@AlexanderNecheff]

> How have you dealt with demands for estimates that you know you can't commit to on software projects? My personal favorite project involved being asked to estimate a new major feature. When I handed over my report, I was told "oh, well we actually have a contractually obligated due date of Y" where Y was my estimate end date X - $SIGNIFICANT_TIME. I did my due diligence to highlight why I thought this was an unreasonable time line. And then I included the correspondence as well as both my original schedule and the schedule backfit to the due date in a document stored in our retention system. It was fun pulling that little memo out when the team delivered after the "due date", but more or less on the money of when I originally estimated we could deliver the feature. :-D All this by the way was on a roughly calendar year time scale which of course makes it all the more impressive the team was able to hit my original time line within margin of error.

[@SzybkiTom]

So many companies do watergile. The agile words, ceremonies and methods are there, but when the rubber meets the road, you realize it's waterfall all along.

[@xilconic]

One of the things I do that feel more comfortable when I give out an estimation, is to not give a single number. I'm giving them a bandwidth. So I think about the extreme happy case and think of an estimation when everything just falls into place perfectly (relevant to the problem at hand): Requirements being crystal clear and unchanging, codebase being easily testable, effortless deployment/release, well factored codebase, code getting reviewing without delay etc etc. And I think about the worst case in the context where if most things go poorer than expected (again, relevant to the problem at hand): requirements unclear and/or keep changing during development, legacy codebase that's hardly tested and very rigid to introduce changes in, repeatedly missing edgecases, painfully long deployment cycles, dependencies on people/teams/software holding you up, etc etc. And then I think about what could be an expectable point between those, where one would face some setbacks but no major ones. Doing this immediately communicates to the other person how unpredictable the estimation really is. And it enables for example the PO or Project Manager to budget according to the risk they are willing to take. (And in a company with toxic office politics, I'll make sure that I've got a paper trail of that bandwidth) When estimating in time (for some context, like described above I would therefore do this 3x typically), I've been experimenting and having relatively good success with the following 2 step: 1. Determine the scale at which I feel I should have the estimation. Seconds? Minutes? Hours? Days? Weeks? Months? Quarters? Years? etc 2. Determine the scope I feel expresses the estimation. Half? One? Few? Many? For me, this helps me quickly formulate some kind of number, without getting into some 'fake accuracy' of overthinking things too much. (again, I believe in a bandwidth instead of a single number) When estimating in story points, I've found the practice of having Reference Stories really helpful to speed up the process, combined with Team Velocity. Estimating ideally wants good precision and good accuracy. Reference Stories can help improve on precision because Team Velocity with over time minimize the bias people might have (consistently being too optimistic or too pessimistic in their estimations). With regards to tackling the accuracy aspect of estimation: break down the work. And then more! I'm currently experimenting with the practice of breaking down to the scope of expected Pull Requests, both to help identify the work that needs to be done (and by making it visible, trackable too which helps in expectation management) and make sure everybody thinks about the problem in the same way. I find this tractable enough when doing Refinement sessions on User Stories. This can help identify User Stories that might be significantly worse or better than the equivalent reference. For Epics level estimation, I think breaking down in expected User Stories is tractable. And then you can use Reference Stories again to get some reasonable number at that scope. When doing planning poker and I'm hesitating between 2 cards: pick the higher one. For me, I know I have a pitfall of being too optimistic, so I should compensate for that tendency. But also in general, I typically hear software project delivering below expectation than ahead. Lastly from a project management and risk management point of view, the higher estimate reduces risk in terms of planning. When I give an estimate (especially in time) I make clear if I'm talking about lead time (when can you exect it to be finished) or manhours (time spent by a developer actually doing something). Or I ask which kind of estimate they are looking for, as these things answer different kind of questions. Lead time is usefull to reason about if a deadline can be met easily, but it's hard to determine the monetary cost or opportunity cost of that work. Manhours are useful to easily reason about opportunity cost, to some degree reason on monetary cost (For it to be trustworthy, you need to take into account efficiency of the developer. In other words, will the developer be very distracted or very focussed) and similarly more difficult to reason about meeting a deadline (again, would need to know the efficiency of the developer). Confusing the two concepts typically lead to the estimate being not dependable. Lastly, I'm currently experimenting in our project where we are doing a Kanban process, to use the throughput metrics we can collect from our workprocess (basically, the number of work items we finish per day) and use a Monte Carlo simulation to generate possible projections of a set of workload. I like this concept because it's again giving a bandwidth of what can be expected and based on how much risk one is willing to take can use the 'generated distribution' to chose a time-budget for the work.

[@HealthyDev]

Tons of great insight and things to consider here. Thanks for sharing this!

[@kourosh234]

a manager who has been programmer himself will not ask you to estimate. problem often is that managers are not programmers. isn't it better to let managers to estimate based on the work done? managers should do something after all! other problem is that many programmers are ass kissers.

[@soberhippie]

As a manager and a practicing programmer, I don't fully agree. One of my roles as a manager is to prioritise tasks and for that, I need to know how much work will it take each of the team members to do their work. Again, I don't need exact numbers and I won't pass death sentences, but, say, if I know that it will take person A two weeks to finish this task, but it will take everybody else a day to do their work on that feature, and there is another one which requires a week's worth of work of everybody but A, I would ask A to work on that long feature, and all others to work on that other one. But I need some estimates for those kinds of decisions.

[@sexygeek8996]

It can be worse: 1. The idiot in charge of the project keeps adding new requirements and changing existing ones, but still expects you to meet your original estimate. 2. They give you a huge amount of poorly-written, bloated code that you have never seen before and want estimates for several big projects using that code. 3. They want estimates for multiple unrelated projects, then tell you to do them concurrently and they expect each one to be finished within the estimated time as if it was your only project. A manager would complain if he saw you working on a different manager's project.

[@DP-cy8xh]

Love your vids. I've got a couple of different strategies. One is to give a different estimate to the ones requested. Estimate how long it's going to be to provide those other estimates (make it generously high, to give time to really research and look into things), and ask if I should spend time working on those estimates instead of my actual work. Another is to provide heavy disclaimers, that the estimate is not a commitment, and that things can and will pan out differently in practice [providing some detailed examples from other recent work experiences]. Also, keeping a paper trail, eg email thread, and making sure that (more reasonable) people with some clout (and a very good existing impression of me who I've worked with very effectively before) are CC'd in. Basically, taking advantage of office politics a bit. Also, padding out estimates a whole bunch to make them pesimistic. If you've done something similar before, make the estimate eg 2-3x as long and give yourself a lot of breathing room to finish earlier and be able to go faster than your estimates. Basically, dragging people's expectations far down, right from the get-go. Rather than eg, being optimistic and keen to impress them. Far better to under-promise and over-deliver, than the reverse. I especially don't want to give people rope to hang me with. I may - in the worst case - end up working like a dog either way - but I have far better peace of mind. Relevant and humorous youtube clip: kzbin.info/www/bejne/bqm1oouPqNCmfMk

[@rnickel3547]

I think that is one thing immature contexts force us to learn: Official Estimate = Honest Estimate times three. I have been to infinite "estimation workshops", in which software engineers look in each others faces and smiling, all knowing, that the above needs to be done. Which makes me sick, since that is the exact opposite of what an estimate is intended to do. I fought for the #NoEstimates idea a lot, but most people cannot get out of known patterns at all. The fundamental understanding, of what software engineering is, that it is mostly mental work which is non-linear, is just missing. We are not digging holes here. An estimate is basically a favor to those who ask for it and not a contract between two parties, and it is so much more complex than a unidimensional number. But that is neither broadly understood nor persisted, so after years of fighting I gave up. My new strategy is to focus on the content of things that are discussed and ask the right questions. When the planning poker starts, I will just not participate, and go with whatever the team, using all the dirty "actual estimates times three" tricks. I hope that over time this mostly meaningless part of the process dies, because people realize it (mostly) doesn't help. PS: I believe there are a couple of things that estimates are good for. That is to identify misunderstanding within the software engineering team when trying to understand requirements. If one guy estimates high and another one low, they might understand the requirements differently. But for this, a planning poker that contains the following values is totally sufficient: [Yes, too f*cking big, no f*cking clue] (+ plus, no need to mention, good listening skills, asking well thought questions etc.).

[@ScottKFraley]

I LOVE that clip!!!

[@ali-13392]

I agree with you and comment by Nickel. But say you gave an estimate of 3 months (your honest estimate was more like 1 month), but client finds someone else with estimate of 40 days and now he pushes you to deliver it at most in 60 days (2 months). How to negotiate and deal with this situation? I'm an individual freelance developer, working through sites like Upwork/Freelancer and I always end up with the dilemma that someone else quoted a lower cost/timeline for the same project and now client might choose them, so they start enforcing on budget and time.

[@aimtodev9009]

This really made a lot of sense! Thank you very much!

[@aidenz4937]

Thank you very much! This is very educational. Making yourself and your partners comfortable is an art. You make very good points and concrete solutions. Thanks!

[@HealthyDev]

Glad it helps! Thanks for the feedback. 👍

[@mmmburger1]

Fantastic video, thank you!

[@HealthyDev]

You’re very welcome!

[@perfectionbox]

you haven't lived until a manager screams "keep coding, godammit!" 🤣

[@HealthyDev]

Lol seriously?? 🤦🏻‍♂️

[@perfectionbox]

Healthy Software Developer Seriously, I've had managers so under the gun that they've yelled "Can you just fucking get *on* with it already?!" There's something about software that brings out the worst in people, or some exec's next yacht purchase is waiting until the ship date

[@ScottKFraley]

I once had a boss who asked me why I wasn't typing. Just, randomly came to my desk and asked me that while I was trying to actually, you know, THINK about what I was trying to do! I was like, I cannot be typing 8 hours a day . Sometimes thinking IS involved. (FACEPALM)

[@HealthyDev]

@@ScottKFraley yeah that would be hard to stay calm while explaining to them why that isn't productive...Ugh :/

[@gkri8390]

@@HealthyDev yes in have also experienced

[@joost00719]

I used to work at a company where the software owner was actually another company, so we would write the programs for the third party. We developers usually had direct contact with the third party, and it was exactly like you mentioned, they demanded numbers. The result was that when I delegated the estimation to a collegue developer, and then when he got back to me I would double the estimate because I just knew there are parts in the system that could potentially be a roadblock. The final result was that the client decided that the estimate was too much, and mentioned that "it's only a small change"... ... we never hit our targets.

[@ChrisAthanas]

Excellent breakdown. The word estimate should be a four letter word in software equal to FAIL.

[@ariosetiawan173]

Wondering there is illustration mode from this video, but thanks for explanation :D

[@arturk9181]

Boss: So, how long will it take? Me: Lemme just pull out my crystal ball

[@HealthyDev]

LOL right?

[@zvxcvxcz]

So... can we get an estimate on how much time it will take to gather info for the estimate?

[@HealthyDev]

Ha yup. This is where I use timeboxes.

[@ScottKFraley]

Is there a transcript of this talk Jayme? :)

[@jordanstewart225]

With estimations, I think it's interesting thinking about risk, and story points (or an estimate). If i think something is only 5 story points, but highly risky i might estimate it to be 8, or even 13 if the business pushes me for an estimate. A lot of the time an estimate does not have a confidence value, or a risk value attached.

[@HealthyDev]

Agreed. In consulting we would try to attach assumptions to estimates. If the assumption proved wrong we could show that we learned about a complication and that we’re not incompetent etc.

[@RasTaIARI]

You're speaking truth. .... and then there's people like Steve Jobs who, when you say "I can do it in 6 months" tells you "great, you've got 4 weeks", and he is being called a genius. kzbin.info/www/bejne/m5SumKSAh9uNa68 (One more, among dozens of other reasons, why I as a developer really don't like apple.)

[@testingcoder]

timecodes would be really helpful! BTW I also made a video on estimations explaining why they cannot be accurate and what to do about it: kzbin.info/www/bejne/bIaYhqN6oq5qbaM

[@JohnSautter]

estimates for big projects still have to get done, budgets need to get set, developers need to get paid, noestimates, no pay. that said I am a big fan of sizing with simple function points with a range outcomes

[@HealthyDev]

I completely disagree, but I won’t argue your points here because I’ve already done that all over the channel. If a business can only get budget for big projects with estimates that’s a constraint they’ve chosen to operate under, not the only way to provide investors with confidence in a software development effort.

[@stephaniecorby1546]

@@HealthyDev I agree in theory, but in practice each of our clients demand both an HLE and a detailed estimate. "Re-educating" is a possible response, but will take time. This industry is pretty old school and we need a solution that works for our org and the client that doesnt drive our developers out the door