2x: Simple rule for software development time estimation [17/100]

Why are deadlines in software development always screwed? 🤔 Let’s discuss!

Over 15 years of software product development, I’ve formulated a rule of thumb: any feature needs two times (2x, hence the name of the rule) longer than I expected. This rule works for more or less experienced teams working on a software development project. Inexperienced teams need, like, three times as long. The rule applies at the level of features, major releases, or any decent chunks of work.

Are you preparing the project for an exhibition half a year from now? You’ll manage to implement exactly two times less than your planned work package. It’s January, and you promise your customers to release a new notification system in the summer? The project will actually be ready next January. Thanks to this rule, I’ve long stopped promising things; I only forecast the time needed for development and multiply the forecasted terms by the required coefficient.

For some, such an estimation process seems an utter mess, chaos making any worthy performance impossible. I understand the urge to plan things, arrange them, and get clear project estimation to lightheartedly communicate it to the clients, map out marketing campaigns and have some healthy confidence in the future. Well, unluckily for us all, very few people in the industry of software development possess the magic skill to assess the amounts of work realistically—that’s why movements like #noestimates proliferate, rejecting software project estimation as such.

Agile estimation framework now offers little to no guidance for time and effort estimation. The Planning Poker technique only causes an experienced developer to burst with laughter (which you have to hold back when a scrum master’s there, of course). Seriously, the team gathers for a Sprint Planning, the Product Owner reads you a User Story, and you’re required to give it a good three minutes of thought and produce some decent estimation in conventional units. Well, godspeed you!

The main reason for poor software development time estimation is high uncertainty in software engineering as such. It’s not like you finished a similar project just yesterday, huh? You do not know what exactly you will do, nor how you will go about it. You might have some ideas, illusions almost, but you can’t reality-check it at this stage. Any software developer knows that reality is a bitch to turn your nice illusions into some harsh survival marathon. Fully imagining the scope of work is therefore not possible for a human. We can’t look into the future of development; about a month ahead is already a great hypothetical leap.

My typical estimating dialogue with a developer goes something like this:

I: Say, Jane, how long do you need to finalize this feature?

Developer: Two weeks tops.

So in two weeks, here I go again:

I: Hey, Jane, almost done, aren’t you?

Developer: Need two more weeks.

The beginning of a task is the worst point for estimating. At that point, we know too little, while gaining additional knowledge is the only way to improve your estimation. The more we know, the more accurate software development time estimations we produce. That’s why if we want to predict better, we need to get to work straight away and eliminate uncertainties one by one. In Extreme Programming, this was called “spikes.” If, after several spikes, the solutions to all the complicated problems become somewhat clear, the general quality of our assessment improves.

Don’t estimate at all

Btw it adapts to your team and grows with it.

Try Fibery

Most teams try to estimate the required time of development without spikes or prototypes. In this case, 2x is a perfectly acceptable error. There’s no way around improving the quality of predictions by accessing the problems hypothetically only, without getting your hands dirty with real work.

One estimation technique is to split a feature into user stories, stories into tasks, and then improve the assessment thanks to the granularity of the tasks. But what happens under the cap of this reasonable approach? You either disregard the uncertainty altogether or already burden your whole development process with the first available solution—that is unlikely to be optimal.

Coming up with a solution during the estimate is a great, huge, dramatic problem. Don’t do it. 🙅

Oh yeah, by the way, this all has nothing to do with simple recurrent tasks. For those, just use Waterfall and not fuck around with Agile.