Estimating - There is no such thing as a 1 hour task

Introduction

Estimations in software development have always been a problem. Many teams and organisations struggle with finding the right way to do estimations. There is no right answer, and it really depends on your organisation. 

If you are measuring by the hour, then perhaps you have struggled with understanding why you are not as profitable as you could be. This may arise from the fact that your lower estimates are just not realistic. I will explain what I mean in the following examples.

In these scenarios we assume that the developer deploys to an environment, then confirms that the functionality works before handing it to a QA/UAT person.

Example 1 - The perfect case (no defects or problems)

In this example I will outline a 1hr task in a "best case" scenario which has no defects or problems. The order of events will differ depending on your processes. 

1. Download repository & get code running locally - up to 0.25hrs
2. Do the work - 1hr 
3. Deploy to a development environment & test (0.25hrs)
4. Commit code, create pull request, & participate in the code review (0.25 x 2 devs = 0.5hrs)
5. Deploy to a QA environment & test (0.25hrs)
6. Tag & cut the release (0.125hrs)
7. Deploy to a UAT environment & test (0.25hrs)
8. Deploy to production environment, put live, then quickly smoke test (0.5)

As you can see, a single 1hr task can actually take 3hrs in a good scenario. This does not even factor in the time of the QA or UAT people. Also, the context switching of doing all these different steps is a significant time drain.  

You are thinking that many tasks together can be bundled, so we would save time on deployments. As you will see in the next example, the math still does not work out.

Example 2 - The perfect case (no defects or problems) with multiple work items

In this example I will outline 5x 1hr tasks in a "best case" scenario which has no defects or problems. 

1. Download repository & get code running locally - up to 0.25hrs
2. Do the work - 5x 1hr 
3. Deploy to a development environment & test (0.5hrs)
4. Commit code, create pull request, & participate in the code review (5x 0.25 x 2 devs = 1.25hrs) - Note: each task has it's own code review
5. Deploy to a QA environment & test (0.5hrs)
6. Tag & cut the release (0.125hrs)
7. Deploy to a UAT environment & test (0.5hrs)
8. Deploy to production environment, put live, then quickly smoke test (0.75)

As you can see, 5x 1hr tasks can actually take 9hrs in a good scenario. We are not really saving much time by bundling. On average, our  1hr tasks are actually taking almost 2hrs per task.

Example 3 - The bad case (defects & problems)

In this example I will outline a 1hr task in a "bad case" scenario which has defects and problems. 

1. Download repository & get code running locally - up to 0.5hrs
2. Do the work - 1hr 
3. Deploy to a development environment & test (0.25hrs)
4. Code does not work. GOTO step 2
5. Commit code, create pull request, & participate in the code review (0.25 x 2 devs = 0.5hrs)
6. Code is rejected. GOTO step 2
7. Deploy to a QA environment & test (0.25hrs)
8. Fails QA. GOTO step 2
9. Tag & cut the release (0.125hrs)
10. Deploy to a UAT environment & test (0.25hrs)
11. Fails UAT. GOTO step 2
12. Deploy to production environment, put live, then quickly smoke test (0.5)

I hope my following calculations are correct...

0.5 + 

1 + 0.25 +

1 + 0.25 + 0.5 +

1 + 0.25 + 0.5 + 0.25 +

1 + 0.25 + 0.5 + 0.25 + 0.125 + 

1 + 0.25 + 0.5 + 0.25 + 0.125 + 0.25 +

1 + 0.25 + 0.5 + 0.25 + 0.125 + 0.25 + 0.5

= over 12hrs

It is important to note that this is a really bad scenario. Something has gone wrong at every part of the process. Failing Code Review and QA and UAT should be very rare. However failing at least one Code Review or QA or UAT is quite common, and should be expected.

Programming is very difficult. So the reality of bugs/issues falls somewhere between the ideal (no defects or problems), and the bad (has issues at all stages).

It is also important to note that unknown obstacles pop up which a developer must address. For example, any frontend developer will know about versioning/dependency issues with their tooling. I have never met a seasoned .net backend developer who has not yelled at the top of your lungs when they realised a Windows update has broken something.

Final Thoughts

In reality there is no such thing as a 1hr task. Even the most ideal scenario has parts of the process which are not accounted for, which can easily push the real time spent to 3hrs. Even bundling items together does not effectively eliminate this reality. 

Programming is hard, and there is no such thing as bug-free software. A release with multiple tasks will have at least one item which is rejected at Code Review, QA, or UAT. Good processes only mitigate defects and problems. 

I hope that this article has given some insight in what it is like to estimate effort in hours. There is no such thing as a 1hr task. What ever your estimation strategy, you need to account for this reality so you can stay profitable.