"How quickly can you get this done?" (estimating workload)

post by kerspoon · 2020-01-18T00:10:55.671Z · LW · GW · 9 comments

Contents

  What is the question?
  Example
  What is 'done'/'complete'?
  Conclusion and Recommendations
None
9 comments

Epistemic status: based partly upon what I learnt as a certified ScrumMaster and mainly from practical experience running a software development team. Some of the later ideas come from Gower Handbook of Project Management, Judgement in Managerial Decision Making, and How to Measure Anything.

When asked how long something will take, you have hidden ambiguity in the question and multiple sources of error. Here we will attempt to clarify both and start to address some of these issues.

What is the question?

Let's start with the ambiguity of the question. Lets ignore ambiguity over the definition of 'finished' and any errors in your estimation for now. Lets also assume that you already have a prioritised list of projects/work-packages, some of which will be in-progress, some wont have been started yet (I will take the terminology from SCRUM and call this the 'backlog' but it can apply to anything, not just projects as we traditionally think of them). Here are a few things that I think people actually mean when that ask "how long will this [project] take?":

1. If you started this now and worked on nothing else (during your usual work hours) when would this task be completed?
2. If you started this project now and worked on no other projects (during your usual work hours), but still had to deal with the usual non-development work (such as meetings, firefighting and emails) when would this task be completed?
3. If you worked on this project as the absolute highest priority work. How many hours would you have spent on this project by the time it is finished?
4. Given that there are other projects that are in progress or even higher priority than this, and that some of your time is spent in non-development work. When will this project be finished?
5. As with 4 but realising that you are likely to add other work into the backlog, some of which will be higher priority than the project in discussion.

There is an important subtlety to the phrasing of these questions which greatly changes their answers. This is not a problem if the questioner and the estimator agree on the definition but if you wanted an answer to variant 5 but got the answer to variant 1 then there is a problem.
Lets go through an example to show how these variants differ and which is the best version in different scenarios.

Example

A customer requested a feature to be added to some software and that you are responsible for the team that is developing the software.

To work out where you should add it to the backlog (i.e. it's priority compared to other things your team could work on) you want to know the "size" of the work, in this case you do not care whether you team has lots of meeting on at the moment or the priority of other projects - thus variant 3 is the best version in this case. Let's say that you have a perfectly accurate and precise predicting machine that says this is 2-hours (I want to revisit this simplification in another post). But it's important to say that number along with the understanding that you cannot actually get the work done in that time. Your team will have non-development work to do, they will have meetings, and need breaks, if you know they have to deal with "firefighting" of emergencies then this needs to be factored in too. You go back to your predicting machine and ask it: what is the current fraction of time my team can focus on development work, it replies with 50%.
Unfortunately the answer to variant-2 is not "in 4 hours time" (2h / 50%) because there will be times when you cannot progress on the project because you are waiting on something (most commonly other people). Lets say for this project you need sign-off from the marketing department roughly half-way through the work (other common reasons might be waiting for access, for information, for the results of other people's work, etc). So we go back to our predicting machine and it says "the reply from marketing will take 3h, there will be no other delays". This give us our answer to variant-2: "the work can be done in 8 hours, but 3 of those hours we will be waiting on others, and 2 of those will be on unrelated non-development work". Note that by being specific when answering these questions you reduce confusion.
This still doesn't help our customer, because we are unlikely to start the work right away. We will probably finish off the work we are on, possibly implement other higher-priority work and then start. We go back to our prediction machine which says "the projects that are in-progress or higher priority than this one (from the backlog) will be complete in 4 days time". We add that to the 8h for the project in question and get the answer to variant-4 "assuming the backlog doesn't change the project will be complete in 5 days". But we know that isn't a realistic assumption, just like this project, we regular add new projects to the backlog and that shifts the priorities and thus the timescales for each item to be complete. We go back to our prediction machine it says "before you get started on the project in question you will add a further 6 days of development work that is higher priority than the project in question". So you have to add this extra 6 days to the 5 days, take into account any weekends and holidays and give the final answer to variant-5, the one the customer actually cares about: "it will be 11 working days to before you can use this feature".
So we have gone from a piece of work that will only take 2-hours to one that will not be ready for 11 working days. This is the scale of the ambiguity.

These figures are not unrealistic either - though I would be working hard as a team lead to increase the 50% development work figure and reduce or eliminate the 3h wait for marketing sign-off.

What is 'done'/'complete'?

Lets add one piece of complexity back in. What do you mean when you say done? Sticking with the example of a piece of software, here are a few possible parts to what you might mean by done, but there are more, and many of those have their own ambiguity:

1. basic functionality works on the machine of one developer: "it's working for me"
2. thoroughly tested
3. thoroughly documented
4. an automatic test suite written that covers every line changed
5. deployed so a (/every) customer can use the feature

Again, there might be a doubling or more of workload between "working on my machine" to deployed and documented ready for customers to use.
The only point I will make on this is to recognise the ambiguity and address it upfront. But unlike the last section the definitions will depend a lot on the area you are working in.

Conclusion and Recommendations

I will leave the advice on how to improve estimation for another time (please let me know if you are interested in this) but there are a few points to take away. Firstly "how long will this take?" or "when can you get this done by?" is a tricky question even if you are a well calibrated (accurate) and precise estimator. It's best to give your answer, not just in hours but as a longer sentence, "it's only 2h work but we wont be done for 11 days" or more verbosely "the work can be done in 8 hours, but 3 of those hours we will be waiting on others, and 2 of those will be on unrelated non-development work. We probably wont start it for another 10 working days though".

9 comments

Comments sorted by top scores.