A long time ago when I was a team lead, we were in a planning session and I made up the rule of doubling. Jokingly, I said we should just double the estimates of all our developers (at the time estimates were in hours or days, not story points). The reason behind it was the fact that doubling would make the outcome more realistic, as I knew the developers were vastly underestimating tasks.

The problem with the rule of doubling is that it compounds. When I told someone how long a feature would take, they doubled it. Then, when that person told someone the date, the next person doubled it. What’s even crazier is the rule of doubling actual yields pretty good results. So as an organization gets larger, the rule of doubling is really the root cause of why projects take longer to get out the door.

I know what you are thinking, I am crazy but it is true. The rule of doubling is a real thing! Why?

There are two main reasons. Developer estimates have very little to do with releasing software and because you never take the time to make the rule of doubling not true.

Developer estimates have very little to do with releasing software because coding is not the only variable involved with releasing software. A great example of this is an article published 7 years ago entitled, How many Microsoft employees does it take to change a light bulb? Microsoft is definitely an extreme case, but I still experience a very similar reality. To release a new feature, the following parties are usually involved.

• Developer codes something
• Designers help if UI changes are involved
• Writers help if text changes are involved
• One or two team members review the code
• One or two team members help to QA the changes
• Project manager works on including information about the change in an upcoming release
• Support and Ops teams discuss upcoming release with Project Manager and Software Development Managers
• Ops and Development team deploy and verify changes for a release

It seems like a lot, but at Rackspace we take Fanatical Support seriously, and what that means from our software development teams is a lot of time spent to release a quality product. I honestly wouldn’t get rid of a single part of this process. All of it makes our software better and hopefully our customers happier.

This is why story points are more accurate. They measure relative size of different pieces of work and then apply past history to estimate for the future. Don’t forget that story points mean absolutely nothing to organizations or customers. If you can’t use story points to give relatively accurate delivery dates, they are worthless.

Because you never take the time to make the rule of doubling not true means that the inefficiencies that slow development teams accumulate over time rarely get fixed. Developers can easily miss the forest for the trees, working slowly on features instead of fixing inefficiencies to work faster on those features. Bad build scripts, lack of testing automation, crappy development environment, and repetitive manual processes are all build ups of technical debt that need to get resolved at some point.

The solution is good Software Development Managers. Managers need to understand the true cost of developing software, both from an initial implementation standpoint and a future maintenance cost perspective. All to often, managers don’t understand software development and hinder a teams success by setting up unrealistic expectations.

As a manager, you need to be able to set realistic expectations around timelines and also make decisions on what technical debt really needs to get resolved and what can wait. Neither of these are easy and I have made my share of mistakes in these two areas over the years. But, as a manager, I need to constantly remind myself of two questions.

Are my teams regularly meeting my expectations around releasing software (and note that if they aren’t, that is probably a managerial problem, not a team problem)?

What roadblocks do I need eliminate to help my teams meet more of my expecations?