Estimates
-
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".