|
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.
|
|
|
|
|
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.
- If, despite all efforts, the deadline will be missed, document the cause, estimate changes, and produce a new deadline. Do your best to ensure this happens, at most, once.
If your organization will not allow you to do all of the above, you have 2 choices:
1. Live with it.
2. Find a new job.
Harsh but true ....
|
|
|
|
|
IMHO, up to 15% off is normal. So, include that 15 percent into the estimate as a buffer, and give that 115% figure as the final estimate. (Don't tell others that there is a buffer, but you know that there is).
It is also true in some cases, that work commences as the deadline approaches.
|
|
|
|
|
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 
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.
One ex-chef of mine answered me in a not so good manner to such comment back then.
My answer was: As if all your offers were the same as the final contract being signed.
He visibly refrained a reply, turned around and left.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: He visibly refrained a reply, turned around and left.
A quick learner then 
Forcing, rudeness; worked well in the 19th century in the coal mines when people depended on the work for their food. Nowadays, if the employer is not friendly, you simply look for one that is and move 
Bastard Programmer from Hell
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.
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 
Bastard Programmer from Hell 
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.
|
|
|
|
|
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?
|
|
|
|
|
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.
|
|
|
|
|
My estimates are always conspicuously wrong.
|
|
|
|
|
|
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.
|
|
|
|
|
My boss doesn't have a high estimate of my changing estimates 
|
|
|
|
|
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.*
| Ravings en masse^ |
|---|
| "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
|
|
|
|
|
Nand32 wrote: What is the percentage of success rates with your dev. estimates?
0%
|
|
|
|
|
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.
<hr>
"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. 😅
|
|
|
|
|
Make it a strength, not a weakness!
Get the estimate, multiply by three and you are good to go!
<hr>
"Qulatiy is Job #1"
|
|
|
|
|
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
|
|
|
|
|
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)
|
|
|
|
|
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".
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
