Stephan Schmidt

Three Fundamentals of Software Estimation

Three things to keep in mind

You should not invest into estimations. You should invest into building features with impact. That is your biggest lever for success, not good estimations. Estimations are mostly for opportunity-driven companies without a vision.

Said that, there are three things managers need to know about estimating software development effort.

The more time you invest into estimation, the smaller the error
Estimates are not timelines
Estimations are not measurements
(+1) The market doesn’t stop

All of these sound trivial but are ignored by managers who want estimations.

The first one means it takes effort that you need to invest into estimations to get lower errors - and all estimations have an error margin.

I have three data points from experience:

You invest 15 minutes, and you get Scrum estimates or T-shirt sizing. The error here is huge, developers argue about a 3, 5 or an 8, and then agree on a number, e.G. 5. The “8” estimate is 166% bigger than the 3 (or 2.7x the estimation)- which is a huge estimation error. T-Shirt sizing is only viable to see if a feature is a small thing (S), a normal thing (M) or too large (XL). The decisions you take away from estimations need to be in line with the error. For T-Shirt Sizing: An XL needs to be broken down, an S you don’t need to account for, it’s trivial, an M takes a sprint.
You invest a day into estimating, and get an estimation with the granularity of months and an error of weeks—adding a buffer of 20% for unknowns to reduce the error and adding 10% for “overhead” (writing documentation etc.) because developers most often only estimate writing code. You do this by looking at what packages, data structures and pages need to be changed.
You invest one or two weeks into estimation, and you get an estimation with the granularity of days and an error of days—adding a buffer of 10% for unknowns to reduce the error and adding another 10% for “overhead.” You do this by planning for new code and development changes to methods, classes, SQL, form fields, storage, etc.

The more time you invest, the better the estimation. With an engineer investing several days into creating an estimation, perhaps impacting others by asking questions about details, one needs to ask: Is it worth it? Shouldn’t the engineer not write code for those weeks?

A core insight I had into software estimation: Software estimation is fractal. The closer you look the bigger the estimate gets. If you want to measure the coastline length of Great Britain, and you measure it on a large map, you will get some length x. If you go into more details, the measurement will get longer because the coastline zigzags more, x gets larger. You zoom in and measure, and x grows again because it zigzags even more. You go to the beach and try to measure the coastline, with the waves going in and out; it’s impossible—there is no spoon.

Same with software estimation. The deeper you look, the more details you find and the more-edge cases, past hacks, unsuited architecture decisions you will find. Your idealized view of the code fades away. Software estimation is fractal the same way the Great Britain coastline is fractal.

Each fractal has a dimension, which describes how it zigzags. A line has the dimension of 1, a square has a dimension of 2. A fractal line has a dimension somewhere in between. The Great Britain coastline has a dimension of 1.25. If you know the fractal dimension of your code, you can multiply a rough estimation with the fractal dimension to get a better estimation (one part of your buffer).

Estimates are not timelines

Estimates are not timelines, although they are both expressed in days. They are often confused. What developers want - if they want to estimate - are estimating effort. What managers want are timelines. This creates lots of problems. To turn an estimation into a timeline, you need to add developers—add reality. Something takes 10 days to develop, you take two developers, it should take 5 days?

No. First, your developers are distracted by many things, company meetings, interruptions from marketing or interesting Slack discussions—or someone is wrong on Hackernews. So a developer only codes 50% of the time. An estimation of 10 days with two developers is - 10-days development time therefore. Surprising, isn’t it? Two developers lose time for communication between them coordinating development. When I am coding by myself, all arguments I have with myself are resolved quickly, because I’m always available to myself and I most often understand myself quite well. This isn’t the case with developers, assuming 10% capacity is lost to communication and alignment, and you end up with 11 days. And the estimation should and is always the ideal time it would take. Then there are holidays, sick days, missed trains and company offsites. So from your experience (and bookkeeping!) at your company, you add 17% to accommodate for average sick days, holidays, etc. - and arrive at 13 days. Deployments need to happen - hopefully you don’t have QA - and you add another day to 14 before a customer accesses the feature.

For an estimation of 10 days, two developers will take 14 days (still with an error, it doesn’t go away!) from start until a customer can access a feature.

From my experience, this detailed estimation takes a lot of effort but works quite fine in the end.

Estimations are not measurements

The third point is, estimations are no measurements. People know that, but after making an estimation, the estimation is often treated as a measurement. Developers are urged to “commit” to their estimation, which they by principle can’t. I ask you, “Estimate the length of your desk,” and you come up with a number. Now I say “Commit to that 240cm.” I measure the desk, and its 260cm. “Why is it 260cm, you committed to 240cm!” - sounds ridiculous, but this is the way software estimations are treated. When I instead measure the desk to 260cm, and you ask me to commit to that number, I say, “I commit myself to 260cm, I’ve measured it twice, it is 260cm.” That’s a whole different thing.

With Scrum, especially story points (3,5,8) are taken as a measurement. The difference between 3, 5 and 8 is huge, but by turning story points into a velocity, and the velocity into sprint capacity, we treat the estimation as a measurement—and forget about it being an estimation with an error margin.

The market doesn’t stop

The last point is, the market doesn’t stop. This makes estimations for larger projects moot, and it is especially larger projects stakeholders want estimations for. Why is it moot? Large projects are bound to change. You base the definition of the large software project on what you think the market wants. But during the long development, you learn that the market wants other things, so the scope is changed to adapt to the market. With the changing scope, adding features or making some other more complex, the estimations are - obviously moot. Stakeholders though will still tell you “But the estimation was 3 months, not six.” If the scope changes in this case, add another month and tell people “Because of adding X the finishing line moves to Y.”

Because of this forth challenge to estimations, it often does not make a lot of sense to estimate things. There are rare cases where you know what to build, but even during rewrites, were you rebuild what you already have; scope changes (that moving target often breaks rewrites).

If you need to make estimations, add the error. E.G. “It takes 4 +/- 1 month.” It’s inconvenient for everyone. But why drop the error, when it is an estimation? And estimating is a Gauss curve.

As a conclusion, estimations are mostly not worth it. If you need them, nevertheless, keep those three points in mind: It takes time to make good estimations, estimations are not measurements, and the market doesn’t stand still while you develop your solution.