How I estimate time for projects

Joel Louzado
Chingu
Published in
3 min readJul 19, 2017

This is something I’m trying to get more mindful of nowadays and I just want to write out my process, maybe someone else will have a better system and they’ll let me know.

When I need to estimate a new project, my steps to go from “Idea” to Proposal are something like this:

Write out user stories.

This are written in active voice, and are kept as simple as possible: “User initiates an event”, “App responds to the event by doing X”, etc.

Group your stories

  • Make one category for minimum viable product, the absolutely necessary features.
  • After that make additional groups of stories as per whatever makes sense.

Expand on the user stories you’ve written

Your user stories are high-level descriptions and the major error that I used to make was to provide estimations of time based on how easy things seem at this level. Things always seem easy at the high level.

Take each story and then in an excel sheet make an excel sheet.

If the user story starts with: “A user logged in”, the feature would be “Accounts Management”, sub features would be “Login”, “Logout”, “Signup”, etc.

Once you’ve written out all your features and sub-features (and there will be some overlap so group all those together) just rank each thing on a complexity scale to make your time estimation easier. You can use your own scale but mine is something like:

  • 1 — low complexity,
  • 2 — basic calculations
  • 3 — basic input / output
  • 4 — high complexity calculations
  • 5 — very complex i/o, integration of external services, etc.

Once you have that, just start putting down hours you’ll need for each task. As you’re going through, if you see that tasks that have the same complexity rating are taking differing amounts of time that’s a possible sign that either:

  • your time estimate is wrong for one of them,
  • your complexity estimate was wrong for one of them, or
  • one of the tasks hasn’t been broken down into small enough pieces yet.

Experience will help you figure out the differences between those signals.

Adding it all up

After you’re done, sum up the total hours required. You’re bound to have been optimistically assigning numbers so go ahead and increase that number by 25% to 50% (depending inversely on how confident you’re feeling).

That’s your final number, except that you might’ve forgotten some (or all) of the following:

  • time for writing unit-tests,
  • time to setup the development pipeline (VCS, issue tracker, wiki, IM channels and automatic hooks for notifications for everything)
  • time for research (if any), and
  • time for client servicing. Because that’s also a thing you need to do to make sure your client knows what’s going on.

Final Thoughts

This is just the process I’ve iteratively landed at after trying various ways to estimate projects. If I've forgotten anything, lemme know. :)

--

--

Joel Louzado
Chingu
Writer for

Writer, programmer, armchair philosopher and (day)dreamer. :)