Estimates
-
What is the percentage of success rates with your dev. estimates? What is the % of deviation you feel is acceptable to a development team. I'm frequently falling off the deadline by 5-10% extra days. When the boss asks to work on a new technology or framework, it's unknown water. Whatever tools we had used already, we do a precise estimate, add some buffer. But whenever (most often) we use a new framework or a technology, the deadline gets slipped marginally. Some heads at the top yell at the deadline miss. It's making the whole team go mad when they put all the efforts to get things working.
Never give them. Never asked. Probably people who can ask me to do something know I'll do it until it's done . . . correctly. Those who they have that do try to meet deadlines (some contractors) mainly turn out shyte that needs to be fixed and patched and finally discarded . . . but they made the deadline. Defects are also a great reason to keep paying them their monthly maintenance. So - maybe they learn, at the management levels that hire contract developers (usually with talking to their own IT development team) that pushing for some date is not necessarily the best idea.*
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
Easy to fix, just make a new estimate.:) I said: "I'll try" Boss heard: "I commit"
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
-
Never give them. Never asked. Probably people who can ask me to do something know I'll do it until it's done . . . correctly. Those who they have that do try to meet deadlines (some contractors) mainly turn out shyte that needs to be fixed and patched and finally discarded . . . but they made the deadline. Defects are also a great reason to keep paying them their monthly maintenance. So - maybe they learn, at the management levels that hire contract developers (usually with talking to their own IT development team) that pushing for some date is not necessarily the best idea.*
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
"Those who they have that do try to meet deadlines (some contractors) mainly turn out shyte that needs to be fixed and patched and finally discarded . . . but they made the deadline. Defects are also a great reason to keep paying them their monthly maintenance." I am a contractor after working 7 years in a real company. I totally agree, especially with the quality of contracting job - often we have to work on piles of dog**** that passed between the hands of many contracting companies, all hurrying up for the lowest price. And, given the prostitution ring that is contracting, we end up doing the same, only to leave another layer of flaming youknowhat to the next unfortunate sap.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
What is the percentage of success rates with your dev. estimates? What is the % of deviation you feel is acceptable to a development team. I'm frequently falling off the deadline by 5-10% extra days. When the boss asks to work on a new technology or framework, it's unknown water. Whatever tools we had used already, we do a precise estimate, add some buffer. But whenever (most often) we use a new framework or a technology, the deadline gets slipped marginally. Some heads at the top yell at the deadline miss. It's making the whole team go mad when they put all the efforts to get things working.
Nand32 wrote:
What is the percentage of success rates with your dev. estimates?
0%
-
Eddy Vluggen wrote:
An estimate is NOT a deadline. It is an estimate and by definition it will not be precise
I just realize how, over a period people have started misusing the word estimate. In my team, they take an estimate for Deadline. WTH. I have missed to ask this basic question when I'm fighting back :) Point noted.
Eddy Vluggen wrote:
Is that with or without moving specs?
Of course, Of course. We have never done a release without modifying at least a tiny bit in the requirements. But they ask like "Okay but you guys take this much to do this change?"
Eddy Vluggen wrote:
If you impose a time-limit, then people will drop stuff simply to stay within the limit. If you want quality and are dealing with an unknown, then you cannot demand a date. Well, you can, but then you get a "when it compiles, we ship it" attitude.
All points noted down. Arming the missiles now.
Nand32 wrote:
I just realize how, over a period people have started misusing the word estimate.
I guess that happens in more places.
Nand32 wrote:
We have never done a release without modifying at least a tiny bit in the requirements.
Doesn't mean that you should say no to any proposed change; but if you have to be flexible with what you do, then the time you get needs to be a bit flexible too. Everything we do, incurs a cost; if time cannot move, quality eventually will. If quality moves, then expenses often move too, since more time and effort goes into finding bugs that could have been prevented by doing it right the first time.
Nand32 wrote:
All points noted down. Arming the missiles now.
From my POV, I'm schooled and paid to identify potential risc to the project; it's nothing personal, so don't make it that. Disarm the nukes and explain that asking the impossible will always result in disappointment. In the long run, it will erode the teams' confidence and with it, productivity. If it is never good enough, people stop trying. If you look at it like that, then it is in everyone's interest (in your company) to improve the situation. Good luck :thumbsup:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Eddy Vluggen wrote:
An estimate is NOT a deadline. It is an estimate and by definition it will not be precise
I just realize how, over a period people have started misusing the word estimate. In my team, they take an estimate for Deadline. WTH. I have missed to ask this basic question when I'm fighting back :) Point noted.
Eddy Vluggen wrote:
Is that with or without moving specs?
Of course, Of course. We have never done a release without modifying at least a tiny bit in the requirements. But they ask like "Okay but you guys take this much to do this change?"
Eddy Vluggen wrote:
If you impose a time-limit, then people will drop stuff simply to stay within the limit. If you want quality and are dealing with an unknown, then you cannot demand a date. Well, you can, but then you get a "when it compiles, we ship it" attitude.
All points noted down. Arming the missiles now.
Nand32 wrote:
I just realize how, over a period people have started misusing the word estimate.
Generally, the Norwegian word "å estimere" has the same meaning as "to estimate" in English. But in some north Norway dialects, it is used in the sense of "value", and almost always negated, about a person: "I do not estimate you" meaning "I have no respect for you, you are worth nothing". A hundred years ago, it was actually used like this all over Norway, both in a positive way, "highly estimated" (like "in high esteem" in English) and negatively. Today, if you tell a south Norway person below 30 years of age that "I do not estimate you", he will probably not understand it as an insult, but rather be curious about which of his physical properties you are not going to estimate - his body weight? Height?
-
What is the percentage of success rates with your dev. estimates? What is the % of deviation you feel is acceptable to a development team. I'm frequently falling off the deadline by 5-10% extra days. When the boss asks to work on a new technology or framework, it's unknown water. Whatever tools we had used already, we do a precise estimate, add some buffer. But whenever (most often) we use a new framework or a technology, the deadline gets slipped marginally. Some heads at the top yell at the deadline miss. It's making the whole team go mad when they put all the efforts to get things working.
The best approach I've seen is taking a realistic estimate, with sensible buffers and margins, and then multiplying the whole thing x3. I find it extremely annoying that there doesn't seem to be a better way.
-
What is the percentage of success rates with your dev. estimates? What is the % of deviation you feel is acceptable to a development team. I'm frequently falling off the deadline by 5-10% extra days. When the boss asks to work on a new technology or framework, it's unknown water. Whatever tools we had used already, we do a precise estimate, add some buffer. But whenever (most often) we use a new framework or a technology, the deadline gets slipped marginally. Some heads at the top yell at the deadline miss. It's making the whole team go mad when they put all the efforts to get things working.
Ah, the joys of treating estimates as deadlines. My advice, don't ever succumb to the management pressure of decreasing your estimates to fit their schedule. Never, ever works. Second, since everything takes longer than you guess, practice inflating your estimates until they actually seem to predict the time it takes. You can actually get good at this with practice. Good management greatly prefer accurate estimates than low-ball estimates that never make schedule. Third, don't accept any tasks/work that anyone, even the janitor, has said out loud, "that's easy". If you get it done on time, no credit because it was easy. If you are late, you must be a bad developer because you couldn't deliver something easy on time. Fourth, if you are ever in a meeting and asked for an estimate, but another manager/developer gives a lower estimate, make them do the work! No matter how much they claim they are too busy to do it. Lowest estimate wins the work. Trust me on this one. Cheers
-
If you're
Nand32 wrote:
frequently falling off the deadline by 5-10% extra days.
then I'd suggest adding 5 - 10% to your estimates. You won't always need it but you won't be delivering late. If you're ready early then you either have time to be more thorough, (including documentation etc), to dig deeper into whatever new tech it is you're using (if it's new and you're on time, it's probably good so you're going to want to use it again, so master it now!), take some time off, or deliver early and bank some brownie points.
The problem goes far beyond the estimate, which is only 1/3 of the situation. First you create an estimate, then you schedule the work using the estimate, THEN you manage the schedule. Estimate:
- Involve the team. Get input from the folks that will be doing the work. Even if some are not good at estimates, this gives them skin in the game. Use it as a teaching tool.
- If new (to the team) technology is involved, add a task to learn the technology. No OTJ, "we'll figure it out". Plan for learning.
- Estimate each task at the task level. If you have a high and a low estimate, use the average or the high, depending on how much you trust the estimates.
- Add a task for reporting, both within the team, and to stakeholders. This can eat a lot of time.
- Do a risk assessment, including technical and non-technical risk. [Management oversight is a risk.] Plan time for managing risks.
- Add 10%-20% to account for the things not accounted for, and for things to simply go wrong. This covers equipment failure, team turnover, etc.
- Add everything up, and even if the number looks ridiculous, it's probably right.
This will give you that extra 5%-10% that's missing, and you can justify everything if management wants a detailed review. Schedule:
- Consider team utilization, e.g., how much of a 40 hour week will actually be spent on the work? I typically use 32 hours, although in a situation where the team is also doing production support, I scheduled for 20 hours/week utilization.
- Plan for holidays, vacation, and sick time. If you work with foreign nationals who take a longer annual vacation to visit family, take that into account.
- Add a week every quarter for things to go wrong. SOMETHING will go wrong; Murphy's Law applies.
Scheduling too tightly is a huge factor in missed deadlines. Manage the Schedule:
- Scope control -- IME this is the largest factor in failed projects. Agree upon scope before the schedule is created. Get this in writing from the stakeholder(s), or get an acknowledgement email.
- Change Management -- Every change gets submitted in writing, is estimated, and the change to scope and project duration is provided to the stakeholder(s). Make them think about what they are asking, and make them realize there are costs, in both time and money. Each requested change costs at least 1/2 day for 1 person to review the change and provide feedback.
-
An estimate is NOT a deadline. It is an estimate and by definition it will not be precise. Do you remember those paper-books with crosswords that you can buy at the train-station? Pick one with 4 stars, and don't look at the amount of pages. Now, estimate how long it will take for you to solve each puzzle. Done? Buy another one with 5 star difficulty, estimate again, and start yelling in the mirror that you were way off and missed the deadline. If you impose a time-limit, then people will drop stuff simply to stay within the limit. If you want quality and are dealing with an unknown, then you cannot demand a date. Well, you can, but then you get a "when it compiles, we ship it" attitude.
Nand32 wrote:
I'm frequently falling off the deadline by 5-10% extra days.
Is that with or without moving specs? Is this falling off always the fault of the programmers, or is there a possibility that your estimate is off due to, say, unexpected pandemics? Aight, more common example - 3rd parties that don't do as promised. Hardware failures. Incompatible API's. And is that with, or without giving "support" for the previous versions? Can you hang up on a customer without a word to keep the "deadline"?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
To follow up on Eddy's example around moving requirements...ask them how long it would take them to bulid a car for you. When they answer they can't say, ask them why not? They know what a car is, don't they? Even better, of course, substitute for "car" something in their sphere of expertise. To be fair, we can't treat these things as academic exercises, either (unless you're in academia, I suppose). At some point, we have to quit refining and release to solve the business need. Likewise, the business needs to accept "good enough for phase 1" and be ready to iterate, even though phase 1 might, knowingly, be a perfect solution.
-
The best approach I've seen is taking a realistic estimate, with sensible buffers and margins, and then multiplying the whole thing x3. I find it extremely annoying that there doesn't seem to be a better way.
Over 20 years developing hardware and software solutions and I agree that 3x the most reasonable/reasoned estimate seems to be the closest to accurate for a complete delivery. I've seen some guys who can get this down to 2.5x, but it is the rare case. This is both personally and for many many developers who have worked under me. As a company owner, my standard has changed. I no longer commit to deadlines. In the rare case when something is critical, we just work like hell, putting in extra hours to deliver as quickly as possible, seeing where things can be shaved to get things done under the deadline.
"Qulatiy is Job #1"
-
What is the percentage of success rates with your dev. estimates? What is the % of deviation you feel is acceptable to a development team. I'm frequently falling off the deadline by 5-10% extra days. When the boss asks to work on a new technology or framework, it's unknown water. Whatever tools we had used already, we do a precise estimate, add some buffer. But whenever (most often) we use a new framework or a technology, the deadline gets slipped marginally. Some heads at the top yell at the deadline miss. It's making the whole team go mad when they put all the efforts to get things working.
No plan ever survives the battle. Not to mention Project Creep...
"I'm too old for this S*it" - Norman Fell in "MASH" the movie (not the deplorable TV ripoff)
-
Over 20 years developing hardware and software solutions and I agree that 3x the most reasonable/reasoned estimate seems to be the closest to accurate for a complete delivery. I've seen some guys who can get this down to 2.5x, but it is the rare case. This is both personally and for many many developers who have worked under me. As a company owner, my standard has changed. I no longer commit to deadlines. In the rare case when something is critical, we just work like hell, putting in extra hours to deliver as quickly as possible, seeing where things can be shaved to get things done under the deadline.
"Qulatiy is Job #1"
I've tried so many approaches over the last decade or so, and I keep running into that "3x best estimate" wall. In practice, this is mostly due to testing delays, feedback delays and the limits of human-to-human communication with regards to design and functional specs. I also noticed that pushing for a 2x estimate in a 2-week sprint, slows down one or two following sprints, making the entire effort pointless. In my experience, this is mostly because the non-developers get tired of the constant communication, and feel that there must be something wrong with the specs. 😅
-
What is the percentage of success rates with your dev. estimates? What is the % of deviation you feel is acceptable to a development team. I'm frequently falling off the deadline by 5-10% extra days. When the boss asks to work on a new technology or framework, it's unknown water. Whatever tools we had used already, we do a precise estimate, add some buffer. But whenever (most often) we use a new framework or a technology, the deadline gets slipped marginally. Some heads at the top yell at the deadline miss. It's making the whole team go mad when they put all the efforts to get things working.
You guys work in some pretty strange places. Where I work top management picks a date, middle management pick a bunch of unrelated sometimes conflicting features (to be fair sometimes top management does this too), then first line management assigns people. Developers then do something, possibly related to a requested feature. Anywhere from a month before to a couple of weeks after the deadline testing and documentation folks are brought in to try to figure out what the developers have done. During this time period top management also decides if the code should be shipped with whatever is there ATM or the date moved. The clear advantage to this method is no time wasted to useless activities like planning or estimating. Oh! and we are "agile" but don't waste time on in-depth stories when we have found that "make feature X work good", or sometimes more formally "As a user I want you make feature X work good" (remember documentation people haven't been involved at that point). This is especially true when no-one knows exactly what feature X is. Oh, oh and we are also now CI/CD (Continuous Irritation/Continuous Divination). This proclamation has lead to an almost limitless productive increase. It use to take days to push a one line change, now it takes weeks or months, but that's what life is like on the cutting edge of the industry. We also have a flawless method of assessing developer value, which is based on the amount of code created, making cut and paste a popular replacement for functions. Developers can also increase their value by fixing their own bugs once the product is in the field, but only once the problem has be elevated to the attention of high level management, where credit for saving the day can be appropriately dispensed. I think the advantages of the above system are clear and hopefully I've convinced you to give up this estimation foolishness in favor of greater developer productivity.
-
I've tried so many approaches over the last decade or so, and I keep running into that "3x best estimate" wall. In practice, this is mostly due to testing delays, feedback delays and the limits of human-to-human communication with regards to design and functional specs. I also noticed that pushing for a 2x estimate in a 2-week sprint, slows down one or two following sprints, making the entire effort pointless. In my experience, this is mostly because the non-developers get tired of the constant communication, and feel that there must be something wrong with the specs. 😅
Make it a strength, not a weakness! Get the estimate, multiply by three and you are good to go!
"Qulatiy is Job #1"
-
What is the percentage of success rates with your dev. estimates? What is the % of deviation you feel is acceptable to a development team. I'm frequently falling off the deadline by 5-10% extra days. When the boss asks to work on a new technology or framework, it's unknown water. Whatever tools we had used already, we do a precise estimate, add some buffer. But whenever (most often) we use a new framework or a technology, the deadline gets slipped marginally. Some heads at the top yell at the deadline miss. It's making the whole team go mad when they put all the efforts to get things working.
As an experienced developer (20+ years), I only try estimate precisely when I'm moving in "known water". If not, I communicate that uncerainty and try to give just a very coarse horizon like "at least two weeks".
