8

I am currently the only software developer in my company. When there used to be other developer(s), we would follow agile scrum method and gather to have sprint planning meeting to try to come up with a story point for all the tasks in the backlog, and then estimate the time necessary to complete the task based on that point. If the task took longer than the original estimate, we would discuss the obstacle and just push it back to next sprint, no biggie. As team of developers we each had solid understanding of why there was delay because we understood how the code is structured.

But now as the only developer, I find it more stressful to report estimated time to my direct boss who is the CEO, and who of course is not part of the software dev but has some background knowledge. He expects the task to be finished within the original estimate, and even if there is unexpected delay it is hard to explain to him since he doesn't know the exact project setup. So then I try as much as possible to finish the task within original estimate, and that sometimes lowers the quality of the code.

I wish that there is a technical person that I could directly report to rather than the CEO, but our company being so small, that isn't really the realistic option now. Is there any suggestion to communicate better with him, or make any change to the current reporting process to make both of our lives easier?

Improve this question
5
  • 8
    We have a question about how to respond when asked for an estimate on the Software Engineering Stack Exchange. – Thomas Owens Jan 8 '17 at 15:09
  • 1
    Estimatimg time to complete a task is a professional skill developed and improved with practice. Sounds like you need to focus on practicing it so you're ready next re. As others have said, there are.some rules of thumb for most professions, starting with "whatever your first guess is, it will take longer and cost more; reality never matches the ideal case." – keshlam Jan 8 '17 at 22:35
  • "How to give estimates" is a dev question and fully answered at the link given by Thomas. It seems like you're actually asking something else related to communication but I can't tell what the actual problem is or what outcome you're looking for. VTC unclear. – Lilienthal♦ Jan 9 '17 at 8:44
  • If you're in a business of reasonable size, look around for 'who' is the communications person, and talk to them. They may be able to help you produce regular written feedback for your employer with a translation from technical to non-technical language. Just something that may help. Otherwise I don't have an answer, just this suggestion. – TolMera Jan 9 '17 at 9:09
  • I wish that there is a technical person that I could directly report to rather than the CEO - There's no gentle way to tell you this... there is such a person in your company, and you're him. – A. I. Breveleri Jan 10 '17 at 5:42
8

First of all: Don't shoot from the hip. If the CEO asks you to estimate a task, tell him that you will have to do an estimation and you will get back to him later.

When estimating the time needed, follow the "Scotty Principle", named after Montgomery 'Scotty' Scott from the star ship Enterprise:

1) Caluculate average required time for completion of given task.
2) Depending on importance of task, add 25-50% additional time to original estimate.
3) Report and commit to inflated time estimate with superiors, clients, etc.
4) Under optimal conditions the task is completed closer to the original time estimate vs. the inflated delivery time expected by those waiting.

Source: https://ipstenu.org/2011/the-scotty-principle/

I will conclude my answer with an dialog from an Star Trek episode:

La Forge: Yeah, well, I told the Captain I’d have this analysis done in an hour.

Scotty: How long will it really take?

La Forge: An hour!

Scotty: Oh, you didn’t tell him how long it would really take, did ya?

La Forge: Well, of course I did.

Scotty: Oh, laddie. You’ve got a lot to learn if you want people to think of you as a miracle worker.

Improve this answer
2
  • Or, as my manager likes to put it... SWAG + Pi^2 * 1.95 – Old_Lamplighter Jan 9 '17 at 14:06
  • 1
    It's actually a great principle to live by, to be honest. Why? Because, honestly, things regularly don't go as smoothly as ideal. And frequently an initial estimate may be based on an ideal. So what you end up quoting is an estimate on what is more likely to be safe to count on. Then, whenever things go ideal, you're credited for being extra efficient. Padding your numbers can often be more honest, not less. – TOOGAM Jul 10 '18 at 2:20
16

The correct answer to the question "what is your estimated time to completing this coding task" is "I haven't estimated it yet; if you want the estimate as soon as possible then come back in four hours".

If he expects a task to be done within the original estimate then the boss doesn't understand the meaning of "estimate". He says "estimate", but he expects "guaranteed delivery time". Since you will find it hard to teach him the difference, you just change what you report from "estimate" to "guaranteed delivery time" - usually that will be about twice as long.

Improve this answer
3
  • 8
    Or three times as long. It includes such things as testing, documentation and unanticipated problems. – Robert Harvey Jan 8 '17 at 15:54
  • 2
    And always provide an updated estimate as soon as you hit a roadblock and have an idea of the time it will take to overcome that - don't wait until the originally estimated time is up to say "well, it's going to be a bit later because..." – HorusKol Jan 9 '17 at 3:16
  • I once was assigned a simple programming task - but with several dependances looking cheesy. I asked for 11 days expecting the worse, everything went right, I just ate 2 days and a half, the thing was accepted at once, and was under heavy fire for heavy overestimating(which was not usual). People who don't do that kind of tasks often fail to get the idea of "uncertainty". – gazzz0x2z Jan 9 '17 at 11:35
6

Coming from the startup world, I almost always answer with:

What is the soonest you need this done?

or

How soon do you need this?

And I usually discuss with the person asking whether (1) they are themselves going to make themselves available to sprint to get this done as well and (2) what features are you willing to forego/what other projects are you willing to sidetrack in order to get this done. I typically find that since I trust the people I work with, I will get a reasonable answer for (1), and I always make sure to mention and appreciate the pressure that I will be putting on them if I am sprinting/working overtime to get a task done (e.g., I need you to test this, I have questions about requirements, I need extra resources).

Don’t hesitate to let them know that you will try your best and that you are committed to getting something done for them in an acceptable timeframe. If you approach your manager as an adversary, you can’t be surprised when he or she treats you the same way.

Improve this answer
3

When estimating for "coding", don't forget to add on time for integrating your code with whatever it needs to integrate with, testing it, documenting it, all the other tasks such as version control, configuration control and so on.

If you have interruptions (meetings, time spent filling in timesheets, etc), include time for them.

Then if these "estimates" are actually guaranteed delivery times, add a big fat contingency on top.

Improve this answer
2

Make sure you not only estimate how long it will take, but how long will it take before you have the time to work on it. If something takes two hours to do, it's very difficult to say when it will be done if you don't even know when you can get started. You have to factor other task times, interruptions, etc.

A pitfall many developers fall into is being too eager to please and not wanting to be the bearer of bad news. Of course he wants things don't on time. Who doesn't? There are a few tricks you can use to help you:

  1. Don't be too quick to give an estimate especially if put on the spot. Tell them you'll look into it and have a better idea then. Make sure you at least get the estimate to them on time or you'll be suspect.
  2. Change estimates quickly. As other things take longer or other unexpected tasks come your way, change the estimate. Let you boss know as soon as possible. If he wants something done sooner, get clarification on other priorities. You can only do one thing at a time.
  3. Develop less technical answers to reasons for being delayed. As a technical person, I know you want to give a specific correct answer. Your non-technical boss does not want to listen to this. Be general. Example: I found a bug. No reason to go into detail.
  4. Make sure you are prioritizing according to what your boss thinks is important. You're not going to be perfect, so if something is going to be delayed, make it something he doesn't think is most important.

You have to understand that estimates are perfect. The problem may be that your boss is making promises to others based on your estimates and doesn't have to enjoy telling them (clients?) it's not going to happen. If this is the case, make sure you're giving yourself more time and don't assume everyone expects everything ASAP.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .