DEV Community

loading...

Cracking The Time Estimation

mkantz84 profile image Michael Kantz Updated on ・3 min read

My take on how to master Time Estimation (TE) in a full stack software development.

story-points-estimating

Source: Story Points vs Hours

My belief is that estimating time for a new feature could be harder mission than developing one.
Understanding that there is a timeline creation for different features is something that needs to take in a closer consideration, and as one gain more experience it's easier to be handled.

We all know how important is being accurate in time estimations:

  1. Pricing determination.
  2. Setting a feature (or a sprint) deadline.
  3. Understanding the next milestone timeline

Personally looking on my journey, it took me quite a while, ~4 years, to find a platform that kept me satisfied and was able to support my tasks at a high level, I also believe that this system may support other developers concurring this issue.

In this article I will explain the system, and I'll demonstrate a live TE breakdown


The System

  1. Separate the task for multiple (and very) small subtasks.
  2. Each task should be time measured.
  3. The minimum time estimating per subtask should be 0.5 day. Even if you think the subtask is less than hour, make it 0.5 day.
  4. Always round the time 0.5 day up. (1.1 days will become 1.5 days).
  5. Combine the subtasks time estimation.
  6. Add 10% collateral time. (Do not round time here).
  7. If you didn't consider tests - Add 20% time. (Do not round time here).
  8. Add 20% time for personal QA.
  9. Round Time up if needed.

girs

Source: 8x8

Use-Case Demonstration

Lets take a simple full stack task and estimate its time

Task

Show a list of all users in the software.
Show maximum of 10 users and add pagination if needed.
Give the option to filter between different users (admin, premium, etc...).

Time Estimation
  1. Subtasks separation:
    • Creating API in the server side, including routes, controllers, interactors, database calls - 0.5 days.
    • Creating a network call from client to server. Make sure it works properly - 0.3 days -> 0.5 days.
    • Updating the server to get page number, filter phrase, and collect the relevant 10 users from DB + Update the client network call + Check the API - 0.6 days -> 1 days.
    • Creating a new page in the client side and show all the users - 0.5 days.
    • Adding filtering section and update calls - 0.5 days.
    • Adding pagination section and update calls - 1-1.2 days -> 1.5 days.
  2. Combining time estimations - 4.5 days.
  3. Adding 10% collateral time - 4.9 days.
  4. Adding tests 20% - 5.9 days.
  5. Adding self QA 20% - 7.1 days.
  6. Rounding - 7.5 days.

clock

Yes - 7.5 days.
It may look a lot, but let me tell you this - After this TE you either deliver it sooner, either deliver with small/non QA rejections, and you'll have the confidence of delivering a good quality task on time.


Hope this will help someone out there :)
Thanks for reading ✌🏼

Discussion (4)

Collapse
eladsc profile image
eladsc • Edited

Great article. I would add: It makes sense to follow actual vs predicted time for the various features and, first and foremost the global tasks (e.g. overhead, unit tests) this helps in improving and fine-tuning the estimations over time (maybe unit tests take me 25% and not 20% on average).

Collapse
mkantz84 profile image
Michael Kantz Author

Great tip and very useful.
Thank you very much!

Collapse
tzabardolev profile image
TzabarDolev

That's very insightful. Thanks.

Collapse
vinegreet profile image
Roman Zots

This system is very helpful, thank you so much for sharing!

Forem Open with the Forem app