How To Estimate Software Development Time

Yes! I am an electronic hardware engineer and have been designing high technology products with HW, FW and SW for a long time. People try to do what I call "Estimation by Synthesis" where they break stuff ddown and say "That bit will take 2 months", etc. This gives hopelessly optimistic estimates. I do "Estimation by Analysis" where I try to find a recent project that is somewhat comparable and use that as a gauge - multiplying and divivding to allow for differences. This usually gets within a factor of 2x up or down, compared with >5x for the synthetic estimate! Syntehtic estimates usually need to be multiplied by Pi to improve them... :) Estimating a whole SW project by creating stories and scoring them is totally fatuous, IMHO. It is completely against the principles and ends up with a hopeless estimate.

Basis of Estimate

Any business owners or P&L accountable people listening to this video? What are your thoughts?

Problem I have with CD, is customer unwillingness to accept the work continuously. They want you go "go-away" until the entire wishlist is done, then complain about the result instead of being part of the process.

I recentlu found this channel and just spent this weekend to watch as many videis as I can! Being in the field for more than 20+ years already thought me about 90% of the things, though now is the time to say a HUGE thanks for validating most of the ideas I came up with and dismissing others. Every video I watched was to the point, presented with great examples and explained in a "as simple as possible" way. Thanks again here, for being a great example on how this is done!

I strongly believe that everyone in our industry should benefit from the knowledge base here. Further more every C-level person(or maybe everyone in the industry) should sit back, take their time and listen closely. I do believe the content here could be a game changer and a reason for success.

Thanks! (again and again)

Great video Dave! Cheers!🎉

I miss that t-shirt

I like how my manager asking me every day "how much time left", despite the fact he received storypoint estimation for this particular task just yesterday. 🤦‍♂

One variable I'm suffering today.
The current technical debt of the project.

The feature was seemingly trivial, so I gave a time estimate for today, it was a simple button inside a Dropbox that displays a modal, right?

Wrong, very wrong, the Dropbox items were rendered from the server, hard coded every item and with only one specific behaviour, hrefs

They don't have any class or Id to reference the item I need to manipulate.

I'm trying to extend that behaviour with no success, I'll try again.

And at the end, this was my mistake, I never ever do the extra mile for any company, I just work the hours I agree, and I like to deliver the dates I say I will deliver, but I underestimated the technical debt (I just started working in this project last week) and now, I'm suffering it.

I'm sure it's technical debt since I had to edit three different files or else it wouldn't compile.

What I'm missing in this video is a discussion of the reasons when and why an estimate might make sense and what currency such an estimate might be made in. For example, it's perfectly reasonable to want to know how much money it might cost to get a solution to some problem to figure out whether it makes sense to pay for it. On the other hand, if I have a team working on a list of prioritized problems (which will usually start out small, since we don't know much, grow while we learn and then start shrinking at some time, when the scope is finally more or less fixed) and just want to know whether a particular problem will be fixed by, say, the end of the mont, any estimation will be a lie. The answer will range between "sureley not" and "almost definitely" depending on how many "increments" I need to finish including the one asked for - and I can give a probablity by counting how many were finished in the last, say, four to eight weeks.

I didn't think I would ever say this, but his picture gives oversimplified criticism of story point estimates.

In short, from data, feature drift should become part of your estimate. Let's say you want to estimate to change the color of a widget. Maybe you can do it in 10 min. If not all is wrong with your code. But that's not when the feature will be ready to ship. What's missing in this estimate is the designers changing their mind after the fact. How do you take that into account? Well, this may not be the first time a frontend feature is implemented, and in the past they changed their minds 5 times after a good night's sleep. That should give you an estimate of about 5 days, say.

The major part of the described estimate comes from data about the project context and can be estimated from data. I found, that this is most often the case. One should definitely take that into account.

So in practice it doesn't matter what you initially thought 5 story points mean. Over time it could turn out to be 5 weeks until the assigned feature is finally done. Well, now you know how long the project will take given the current set of features.

The mortal enemy of software developers is the guy in marketing who sells features that don't exist yet. My previous employer (whom I left only because pay was not competitive) rarely set deadlines for development, and this freed us to do everything right the first time. Each developer had a list of projects, of varying priorities. If the high-priority projects were blocked, they has lower-priority projects on which to work. There was no feature branching.

This channel is absolute gold.

Good content! And I like your explanation of precision and accuracy.
Personally, my estimate multiplier is Pi. It's worked out well so far.

16 minutes and 30 seconds in and still no word about how long it will take to get the teleporter working.

The customer or client project manager will not accept that. 😂

Uh oh. These videos are side-tracking me. Like them though. Gotta employ some discipline and watch these things in a metered way.

Great words. That totally makes sense to me... but not to my managers 😆

Very limited usefulness from this video. He mentions off-handed that you would take a very different approach when estimating a large project like for sale to a client vs. a few stories for the next sprint.

He then completely ignored the former and focusef only on the latter, simpler, easier case.

You'll have to break down a task into its components anyway to be able to tackle it better, might as well use that for your up-front estimates too.

No, "Estimate" is a fancy word for "Educated Guess". Of course that can be even more dangerous because "Educated Guess" implies it is more accurate / reliable than it really is.

I find that the best way to estimate is to forget all specific details of the current project/task and to think about similarly complex and small/large tasks/projects in the past and how long those took. Then just take the maximum of those previous ones and that will be a fairly good estimate. If you are doing something genuinely unlike everything you've done so far then ask people who have such experience. The beauty of this method is that it does not rely on any specific project details. Of course the aim here is a ballpark estimate - 1 man-day vs 10 man-days vs 100/1000 man-days...not an exact number of days. So in this way it is like the T-shirt size method.

I am starting to suspect that estimates are more of a tool to make the development team commit to a delivery. Especially that it happens after a contract was signed with a customer and most likely the dates and cost was already decided before the contract was signed. Starting from this premise, it is evident that estimations are a waste of time and at most can be used to see how far off are we from the targets and for the business to find was of mitigating the delays.

I've used function point analysis a few times and it worked for me. Overtime you can fine tune the function point weights to get even better estimates for your specific environment.

The best estimates are no estimates, or use sizes like 1, TFB or NFW

Not just the freedom, but seems the ultimate definition of Agile, that Agile seems to leave behind when not following a plan...err as it follows the plan planned out during planning.

Always seems contradictory, but figured I was being daft over something I was simply failing to understand proper, but CD seems a bit more natural as the actual flow. Trying to integrate a happy union of the two as sort of Agile Alchemy a little CD a little Kanban and a little SCRUM I think we can have something nicer than each by themselves which have their points.

But I ain't one to gossip... .

You give them estimate, they give you fixed price...

The drawback to be aware of is that companies of all types game the statistics. So 8 HTML changes equals 8 points, also creating an API equals 8 points.

Dave, the bad news is that despite the very "Accurate" and "Precise" facts you've mentioned, senior management and businessmen still need an "Estimate”, so, my advice, sell them an optimistic estimate (in the feels and looks), but very conservative from the inside, this is the best approach.
Unfortunately, scientific approach does not apply to how most businessmen think or practice.
And they are right, sometimes. You still need to have a margin for gambling. This narrow margin can make or break the company (I know), but when it works, the businessmen will take all the credit, if not, it’s the developers' fault...!

This guy is full of crazy ideas, but I'm buying what you're selling here....

In my experience - 40 years of Software design and development - I can tell you that almost all projects go as follows:

1) The customer decides what it will cost.
2) The customer decides when it must be finished.
3) The users tell you what they think they need.
4) You make an estimate based on 1)
5) You start designing the software
6) The users change their mind every week.
7) The customer's project leader - who doesn't know anything about software development - asks you if it cannot be done faster and for less money.
8) Go to any of the previous steps.

By the way, I am talking about global players.
Thank God I am almost 68...

What developer works on a story is not a factor in estimating the story point. It's all about complexity and effort. What a BS! The effort is less for a seasoned developer and more for an inexperienced developer. Duh! In story estimation sessions, it is not uncommon to see a senior developer put a 3 point as an estimate while a junior developer puts an 8. Then, the scrum master goes through endless rounds of "tell us why you picked X" conversations and wastes everyone's time. After a 30-minute pointless negotiation, the team lands on 5. Multiply that time by the number of stories the team goes through in the estimation session. What a waste of time...

This was a very interesting listen. In my previous job, at a very small company, the owner was very insistent on getting estimates for entire projects at a time and was very upset if they turned out to be inaccurate but was also very upset if they were too long. Now I'm consulting for IBM, and it is as though they'd heard this exact talk some years ago and have built these ideas into their processes. You can easily guess which job is less stressful and more productive.

As à Product manager I often get to see both sides. Contract worth big money (and commission), verses fluffy specs and a “ideological” approach to estimate are Satans love child.

What tended to work well was to make t shirt estimates and then ask customer to pick key ones. We would commit to those by date X. Other t shirts delivered and paid for in a soon as ready.

Company got a commitment to revenue, customer had a promise of essential delivered on a certain date.

Did we always get it right….. no. Specs change, surprises happen, but there was less panic and heat.

It brought sales and development working together rather than beating each other up. Best day was when head of sales turned down a contract based on an estimate. Trust was key. The big fish contract we were working on came home on time.

The question i usually get when making an estimate that is longer than a few days is ”okay, so how do we make it shorter?”.

Its really ”your estimate is disqualified”, so why bother asking me from the start?

This is something I have been looking for a long time! Thanks for sharing your expertise

‘Simple’ change gets me each time 😂

Summary:

Perfect plan in this context:

1. Understand the goal
2. Know all the steps to achieve it
3. Know how long each step will take
4. Predict all interruptions and miss-steps

Estimate = Let's guess about the future

Accuracy != Precision

mostly we are inaccurate at start of a project by 4x

"Error Bounds" Matter!
Extrapolate from past performance
Small time-horizons increase Accuracy of guesses.

How to estimate:
1. Compare new work with old
2. Identify work of similar complexity
3. Use the actual time it took as estimate for new work

When starting to work on estimation:
1. Bring 4 people together who will be involved or could be involved in doing the work
4. around 4 people is good

Estimate base on T-shirt sizes:
small, medium, and large
If it's extra large, break it to smaller pieces

Throwing Estimates
Play rock/paper/scissors with T-shirt sizes
If estimates agree, move on
At this stage, we are not seeking a prefect design
Discuss outliers

Great explanation.

I quite working with deadlines long ago, we get much better results that way

GOLD content

I was brought into new to a new team and was being "forced" to estimate a large project once. The team had no history, and no one on it knew much about what all needed to be done. I analyzed the work and produced an estimate that I was very unhappy with. I told the manager "here you go but it's b*******". She was pretty unhappy with that response, and I felt bad about it. I found McConnell's 2006 Bill "Software Estimation" and it really helped frame the problem. We re-estimated and reframed the estimate with a lot of his material including the Cone of Uncertainty. It went down much easier this time.

There are reasons people want estimates, and they are not terrible because they want them. And estimates do provide an opportunity for the team to understand the work. It takes time to do that though and McConnell does stress that and has a take on diminishing returns of re-estimation.

Overall, for most software projects it's art not science. McConnell states this as well and does a great job at looking at the science of estimation and how it only applies to a narrow set of cases.

I love all your videos. Best source to practice interview questions

Quick method for a scientific estimate: Think it through to get a base number, double it, and then multiply by Pi. Because Pi will make it scientific - the more decimal places used, the more precise the estimate.
😉

It's not about perfect plans. That's the strawman fallacy that is used as an argument against estimates all the time. It's about the need to converge with other teams at certain moments (within some range). In most non-trivial organisations this is completely normal and unavoidable. Perhaps the IT industry should become a bit more professional like other industries have, instead of taking the easy way out and proposing a "just trust us and wait for it" approach. You can't manage an organisation that way

Guesstimates