Mixing
Answering “how long will this take?†when you don't know [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
This question already has an answer here:
When asked about a completion date, what is the best way to say “it will be done when it is done�
11 answers
My manager gives me tasks to build a program around. After giving me the task, and making any changes to it, he asks me how long it will take. I realize this is an important question for managers. I'm new at software dev and not sure how to answer this. I've never coded the task before, so I don't really know.
I find the time taken can be broken down into 3 parts 1) understanding the task 2) building the program 3) trouble shooting / fixing bugs (I've heard, and agree with, that most of the time in development is spent trying to get the already existing code to work).
time-management tech-industry
asked Aug 6 '15 at 19:23
noteme123
27536
marked as duplicate by DJClayworth, Lawrence Aiello, David K, gnat, yochannah Aug 6 '15 at 21:44
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
suggest improvements |Â
up vote
0
down vote
favorite
This question already has an answer here:
When asked about a completion date, what is the best way to say “it will be done when it is done�
11 answers
My manager gives me tasks to build a program around. After giving me the task, and making any changes to it, he asks me how long it will take. I realize this is an important question for managers. I'm new at software dev and not sure how to answer this. I've never coded the task before, so I don't really know.
I find the time taken can be broken down into 3 parts 1) understanding the task 2) building the program 3) trouble shooting / fixing bugs (I've heard, and agree with, that most of the time in development is spent trying to get the already existing code to work).
time-management tech-industry
asked Aug 6 '15 at 19:23
noteme123
27536
marked as duplicate by DJClayworth, Lawrence Aiello, David K, gnat, yochannah Aug 6 '15 at 21:44
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
I'm voting to close this question as off-topic because I think it belongs in programmers.
– Lawrence Aiello
Aug 6 '15 at 19:55
Your boss must be new to his position if he expects a novice to know how to size a job. At your experience level he basically wants you to "schedule a breakthrough", i.e. do something impossible. Were I in your place (and I have been), I'd say "I don't know. I don't have enough experience yet to be able to size the problem". That might not be what he wants to hear, but it's honest, which is the safest thing for you unless he's incompetent.
– MMacD
Nov 22 '16 at 19:51
suggest improvements |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
This question already has an answer here:
When asked about a completion date, what is the best way to say “it will be done when it is done�
11 answers
My manager gives me tasks to build a program around. After giving me the task, and making any changes to it, he asks me how long it will take. I realize this is an important question for managers. I'm new at software dev and not sure how to answer this. I've never coded the task before, so I don't really know.
I find the time taken can be broken down into 3 parts 1) understanding the task 2) building the program 3) trouble shooting / fixing bugs (I've heard, and agree with, that most of the time in development is spent trying to get the already existing code to work).
time-management tech-industry
asked Aug 6 '15 at 19:23
noteme123
27536
This question already has an answer here:
When asked about a completion date, what is the best way to say “it will be done when it is done�
11 answers
My manager gives me tasks to build a program around. After giving me the task, and making any changes to it, he asks me how long it will take. I realize this is an important question for managers. I'm new at software dev and not sure how to answer this. I've never coded the task before, so I don't really know.
I find the time taken can be broken down into 3 parts 1) understanding the task 2) building the program 3) trouble shooting / fixing bugs (I've heard, and agree with, that most of the time in development is spent trying to get the already existing code to work).
This question already has an answer here:
When asked about a completion date, what is the best way to say “it will be done when it is done�
11 answers
time-management tech-industry
asked Aug 6 '15 at 19:23
noteme123
27536
asked Aug 6 '15 at 19:23
noteme123
27536
asked Aug 6 '15 at 19:23
noteme123
27536
asked Aug 6 '15 at 19:23
noteme123
27536
27536
marked as duplicate by DJClayworth, Lawrence Aiello, David K, gnat, yochannah Aug 6 '15 at 21:44
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by DJClayworth, Lawrence Aiello, David K, gnat, yochannah Aug 6 '15 at 21:44
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
I'm voting to close this question as off-topic because I think it belongs in programmers.
– Lawrence Aiello
Aug 6 '15 at 19:55
Your boss must be new to his position if he expects a novice to know how to size a job. At your experience level he basically wants you to "schedule a breakthrough", i.e. do something impossible. Were I in your place (and I have been), I'd say "I don't know. I don't have enough experience yet to be able to size the problem". That might not be what he wants to hear, but it's honest, which is the safest thing for you unless he's incompetent.
– MMacD
Nov 22 '16 at 19:51
suggest improvements |Â
I'm voting to close this question as off-topic because I think it belongs in programmers.
– Lawrence Aiello
Aug 6 '15 at 19:55
Your boss must be new to his position if he expects a novice to know how to size a job. At your experience level he basically wants you to "schedule a breakthrough", i.e. do something impossible. Were I in your place (and I have been), I'd say "I don't know. I don't have enough experience yet to be able to size the problem". That might not be what he wants to hear, but it's honest, which is the safest thing for you unless he's incompetent.
– MMacD
Nov 22 '16 at 19:51
I'm voting to close this question as off-topic because I think it belongs in programmers.
– Lawrence Aiello
Aug 6 '15 at 19:55
I'm voting to close this question as off-topic because I think it belongs in programmers.
– Lawrence Aiello
Aug 6 '15 at 19:55
Your boss must be new to his position if he expects a novice to know how to size a job. At your experience level he basically wants you to "schedule a breakthrough", i.e. do something impossible. Were I in your place (and I have been), I'd say "I don't know. I don't have enough experience yet to be able to size the problem". That might not be what he wants to hear, but it's honest, which is the safest thing for you unless he's incompetent.
– MMacD
Nov 22 '16 at 19:51
Your boss must be new to his position if he expects a novice to know how to size a job. At your experience level he basically wants you to "schedule a breakthrough", i.e. do something impossible. Were I in your place (and I have been), I'd say "I don't know. I don't have enough experience yet to be able to size the problem". That might not be what he wants to hear, but it's honest, which is the safest thing for you unless he's incompetent.
– MMacD
Nov 22 '16 at 19:51
suggest improvements |Â
1 Answer
1
active
oldest
votes
up vote
10
down vote
Below is my original answer to a similar question on Programmers. I think that it entirely applies to your situation. If you have any further questions, feel free to leave a note - I can add additional explanations.
From The Pragmatic Programmer: From Journeyman to Master:
What to Say When Asked for an Estimate
You say "I'll get back to you."
You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.
In the section, the authors recommend the following process:
- Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
- Make sure you understand what is being asked. Determine the scope of the problem.
- Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
- Calculate the estimate based on your model.
- Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
- Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.
edited Apr 12 '17 at 7:31
Community♦
1
answered Aug 6 '15 at 19:28
Thomas Owens
13.4k45368
3
And make sure to include time for non dev things like meetings and answering emails about the task and QA time and time to document and to get the requirements right before you start and to deploy into your estimates. Most people think only about the dev time but that is often much less than half the time to actually accomplish the whole project.
– HLGEM
Aug 6 '15 at 19:38
2
And...develop the habit now, early in your career, of measuring your work while you're doing it. Keep stats on the type of project, the relative size, and the number of hours/days it takes to complete things (through QA, docs, support, etc). Over time, you'll figure out the best metrics to track. This is just a list to get you thinking.
– Kent A.
Aug 6 '15 at 19:42
suggest improvements |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
Below is my original answer to a similar question on Programmers. I think that it entirely applies to your situation. If you have any further questions, feel free to leave a note - I can add additional explanations.
From The Pragmatic Programmer: From Journeyman to Master:
What to Say When Asked for an Estimate
You say "I'll get back to you."
You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.
In the section, the authors recommend the following process:
- Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
- Make sure you understand what is being asked. Determine the scope of the problem.
- Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
- Calculate the estimate based on your model.
- Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
- Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.
edited Apr 12 '17 at 7:31
Community♦
1
answered Aug 6 '15 at 19:28
Thomas Owens
13.4k45368
3
And make sure to include time for non dev things like meetings and answering emails about the task and QA time and time to document and to get the requirements right before you start and to deploy into your estimates. Most people think only about the dev time but that is often much less than half the time to actually accomplish the whole project.
– HLGEM
Aug 6 '15 at 19:38
2
And...develop the habit now, early in your career, of measuring your work while you're doing it. Keep stats on the type of project, the relative size, and the number of hours/days it takes to complete things (through QA, docs, support, etc). Over time, you'll figure out the best metrics to track. This is just a list to get you thinking.
– Kent A.
Aug 6 '15 at 19:42
suggest improvements |Â
up vote
10
down vote
Below is my original answer to a similar question on Programmers. I think that it entirely applies to your situation. If you have any further questions, feel free to leave a note - I can add additional explanations.
From The Pragmatic Programmer: From Journeyman to Master:
What to Say When Asked for an Estimate
You say "I'll get back to you."
You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.
In the section, the authors recommend the following process:
- Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
- Make sure you understand what is being asked. Determine the scope of the problem.
- Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
- Calculate the estimate based on your model.
- Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
- Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.
edited Apr 12 '17 at 7:31
Community♦
1
answered Aug 6 '15 at 19:28
Thomas Owens
13.4k45368
3
And make sure to include time for non dev things like meetings and answering emails about the task and QA time and time to document and to get the requirements right before you start and to deploy into your estimates. Most people think only about the dev time but that is often much less than half the time to actually accomplish the whole project.
– HLGEM
Aug 6 '15 at 19:38
2
And...develop the habit now, early in your career, of measuring your work while you're doing it. Keep stats on the type of project, the relative size, and the number of hours/days it takes to complete things (through QA, docs, support, etc). Over time, you'll figure out the best metrics to track. This is just a list to get you thinking.
– Kent A.
Aug 6 '15 at 19:42
suggest improvements |Â
up vote
10
down vote
up vote
10
down vote
Below is my original answer to a similar question on Programmers. I think that it entirely applies to your situation. If you have any further questions, feel free to leave a note - I can add additional explanations.
From The Pragmatic Programmer: From Journeyman to Master:
What to Say When Asked for an Estimate
You say "I'll get back to you."
You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.
In the section, the authors recommend the following process:
- Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
- Make sure you understand what is being asked. Determine the scope of the problem.
- Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
- Calculate the estimate based on your model.
- Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
- Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.
edited Apr 12 '17 at 7:31
Community♦
1
answered Aug 6 '15 at 19:28
Thomas Owens
13.4k45368
Below is my original answer to a similar question on Programmers. I think that it entirely applies to your situation. If you have any further questions, feel free to leave a note - I can add additional explanations.
From The Pragmatic Programmer: From Journeyman to Master:
What to Say When Asked for an Estimate
You say "I'll get back to you."
You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.
In the section, the authors recommend the following process:
- Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
- Make sure you understand what is being asked. Determine the scope of the problem.
- Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
- Calculate the estimate based on your model.
- Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
- Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.
edited Apr 12 '17 at 7:31
Community♦
1
answered Aug 6 '15 at 19:28
Thomas Owens
13.4k45368
edited Apr 12 '17 at 7:31
Community♦
1
edited Apr 12 '17 at 7:31
Community♦
1
edited Apr 12 '17 at 7:31
Community♦
1
1
answered Aug 6 '15 at 19:28
Thomas Owens
13.4k45368
answered Aug 6 '15 at 19:28
Thomas Owens
13.4k45368
answered Aug 6 '15 at 19:28
Thomas Owens
13.4k45368
13.4k45368
3
And make sure to include time for non dev things like meetings and answering emails about the task and QA time and time to document and to get the requirements right before you start and to deploy into your estimates. Most people think only about the dev time but that is often much less than half the time to actually accomplish the whole project.
– HLGEM
Aug 6 '15 at 19:38
2
And...develop the habit now, early in your career, of measuring your work while you're doing it. Keep stats on the type of project, the relative size, and the number of hours/days it takes to complete things (through QA, docs, support, etc). Over time, you'll figure out the best metrics to track. This is just a list to get you thinking.
– Kent A.
Aug 6 '15 at 19:42
suggest improvements |Â
3
And make sure to include time for non dev things like meetings and answering emails about the task and QA time and time to document and to get the requirements right before you start and to deploy into your estimates. Most people think only about the dev time but that is often much less than half the time to actually accomplish the whole project.
– HLGEM
Aug 6 '15 at 19:38
2
And...develop the habit now, early in your career, of measuring your work while you're doing it. Keep stats on the type of project, the relative size, and the number of hours/days it takes to complete things (through QA, docs, support, etc). Over time, you'll figure out the best metrics to track. This is just a list to get you thinking.
– Kent A.
Aug 6 '15 at 19:42
3
3
And make sure to include time for non dev things like meetings and answering emails about the task and QA time and time to document and to get the requirements right before you start and to deploy into your estimates. Most people think only about the dev time but that is often much less than half the time to actually accomplish the whole project.
– HLGEM
Aug 6 '15 at 19:38
And make sure to include time for non dev things like meetings and answering emails about the task and QA time and time to document and to get the requirements right before you start and to deploy into your estimates. Most people think only about the dev time but that is often much less than half the time to actually accomplish the whole project.
– HLGEM
Aug 6 '15 at 19:38
2
2
And...develop the habit now, early in your career, of measuring your work while you're doing it. Keep stats on the type of project, the relative size, and the number of hours/days it takes to complete things (through QA, docs, support, etc). Over time, you'll figure out the best metrics to track. This is just a list to get you thinking.
– Kent A.
Aug 6 '15 at 19:42
And...develop the habit now, early in your career, of measuring your work while you're doing it. Keep stats on the type of project, the relative size, and the number of hours/days it takes to complete things (through QA, docs, support, etc). Over time, you'll figure out the best metrics to track. This is just a list to get you thinking.
– Kent A.
Aug 6 '15 at 19:42
suggest improvements |Â
I'm voting to close this question as off-topic because I think it belongs in programmers.
– Lawrence Aiello
Aug 6 '15 at 19:55
Your boss must be new to his position if he expects a novice to know how to size a job. At your experience level he basically wants you to "schedule a breakthrough", i.e. do something impossible. Were I in your place (and I have been), I'd say "I don't know. I don't have enough experience yet to be able to size the problem". That might not be what he wants to hear, but it's honest, which is the safest thing for you unless he's incompetent.
– MMacD
Nov 22 '16 at 19:51