For instance, without writing tests a developer could complete a certain task in 5 days ...

The cynic in me asks, "How do you know a task is complete without tests to show that the code works?" There is also the other side of the coin, which is that you cannot afford to unit test everything throroughly. Somewhere in the middle is a happy medium.

Initially, there are two costs of writing unit tests, but the cost isn't so much in the time spent as the effort. For unit tests to be effective, you need a software design that lends itself to unit testing, and you need good tests. You'll have to learn how to create those through training and experience. While the design is often done by a few senior people, everybody on the team will need to know how to write tests efficiently and effectively. That is, quickly write a small number of tests that catch a lot of bugs; do not spend a long time writing many tests that are unlikely to find bugs.

From my own experiences, I usually lose nothing by writing unit tests. It is rare that I write any sizable amount of code with no serious bugs in it on the first try. The unit tests find the big bugs, and that means I don't have to debug the whole stack. So, as a rough approximation, the amount time spent remains the same, but the quality goes up and the amount of frustration goes down.

Once your team learns effective unit testing, I expect that the estimated time to complete a task will not change significantly. What you will notice, though, is that with unit tests you more reliabily get the tasks done in the estimated time. Predictability is really what the boss wants anyway.