2 ms·
What I've learned in engineering (any form, including software) is take the estimate (acquired in any decent enough way like averaging) and multiply by PI (or 3
by consp 8y ago
What I've learned in engineering (any form, including software) is take the estimate (acquired in any decent enough way like averaging) and multiply by PI (or 3 if that suits you) to get a reasonable amount. In practice it works more accurately for larger sums than smaller ones so your mileage may vary. I guess it is easier for everyone to guess smaller workloads more accurately.
In my practical experience, I multiply the amount gathered from the previous statement by two to have sufficient negotiation space for people 'higher up the chain' who have no idea about anything of this and simply pull estimates out of thin air or their rear without any proper experience except "previous time it was xxx so it should be the same" (which it almost always is not).
edit: I prefer to have some time left on larger projects to avoid overrunning, even though that might be common practice. Usually though time is cut short due to delivery constraints or selling a product before asking the development and you get the 'wasn't it done yet?' speech.
- knightofmars 8y agoHere is the "chart" that I use when determining how accurate an engineer's estimate will be. The left column is the hour estimate to look up the volatility from. The right column represents the potential volatility (probability of increasing in time) of the work item based on the hour estimate. Hour Estimate : Volatility Level 1 - 5 : Little to no volatility. 5 - 15 : Small volatility (a day, maybe two). 15 - 30 : Medium volatility (multiple days). 30 - 60 : Medium to High volatility (days to weeks). 60+ : High volatility (multiple weeks). The reason behind this chart is that when determining what goes into a release there is a tendency to treat all items as static in size. What I mean is that most people will say, "Three 15 hour work items are equal to one 45 hour work item." or "Six 5 hour work items are equal to one 30 hour work item." The worst offender, "Four 15 hour work items are equal to one 60 hour work item." Additionally, as a work item increases in size the amount of "knowable things" increases as well. Of those "knowable things" there are many known knowns, known unknowns, unknown unknowns (thank you DR for that gem). There's a near 0% chance that a team will get all of the requirements in place up front on a 60 hour case. If a scoping team is told that they have 240 available hours to work with, then they will pick a combination of items that fit within the 240 hour box. If they have four high priority 60 hour estimate items then they may pick all four for the release. In the event that four 60 hour items are chosen I would place a near 100% guarantee that the release will not go out within the 240 hour time frame. I would even wager that will be up to four weeks late.