Back
Apr 11, 2016

How we meet our estimations

Estimations are important, but they are just part of equation. We do our best to make them as accurate as possible, but they are not as important as planning and updating plan.

At first, client specifies a goal, like:

  • have product ready for presentation on specific event
  • develop an MVP with specified limited budget
  • increase application user base

In order to reach given goal, we come up with a set of steps towards it. This set of steps is a plan. Plan always depends on context - set of people in your team, available tools, etc. Estimations just tell us how much time each step will take.

Now there's one thing about estimations - they are never 100% accurate. There's always some tasks that take more time then expected (by the way, it's far more rare case that task takes less time, so it's not Gaussian distribution). There's similar thing about context and goal - something always changes. Developer might get sick, client might want to ask for completely different set of features based on meeting with investors and so on.

When something goes wrong, there's just one thing you can do: update your plan given new situation. The worst possible thing to do wold be to continue doing what you were doing hoping that it will figure it out itself.

Workflows we are using are built to optimize two things:

  • have estimations as accurate as possible
  • be notifies when something goes wrong as soon as possible to react accordingly

Estimations

Feature level estimation

When initial plan is made, we split project into features. Those are functionality pieces that can be deployed and seen by client. Each feature is estimated in t-shirt size (XS - XXL). We have a reference scale that allows to assign sizes pretty quickly. Using our statistics from past projects, we can convert sizes to hour ranges. This approach works surprisingly well for initial estimations and allows to see if we meet business requirements early in the process. Range as a result is also a good thing - there's some place for maneuver in case features change a little.

Task level estimation

Each developer receives couple features at the beginning of the sprint. By this time we have detailed spec and feature can be split into smaller steps. Each step is estimated in hours, up to 4 hours each in our case. It's simple to catch possible problems at this stage:

  1. When developer allocates 8 hours to some chunk of work and can't split it into smaller parts - it means that he doesn't understand task good enough and you need to clarify spec.
  2. When sum of tasks estimations is out of feature estimated range - it might also mean that task is not understood either by developer or by manager.

We use our statistics engine to adjust tasks estimations at this point, which makes things even more predictable.

Plan readjustment

Our approach allows to make readjustments at such points:

Feature spec is started

As feature is discussed in details, it's easy to observe if feature size is different from initially assigned one. It's very cheap to replace or adjust feature itself at this stage.

Feature is split into steps

When individual tasks don't fit into feature range - we can come up with different implementation approach, rearrange other tasks in sprint and of course adjust feature. Feature update is not as cheap as in previous step, but still is much simpler than when feature is almost done.

Overtime on individual task

Overtime on individual task is not often, but still happens from time to time. Usually it's enough just to review implementation approach and still meet feature estimation. When different approach doesn't help and more time is required - we're still in good shape: at this point we still have time allocated for this specific feature and we have time left for sprint, so it's easy to avoid last minute panic before deadline.

Subscribe for the news and updates

More thoughts
Oct 3, 2022Management
Task Estimation in Gearheart: Predictions (Part 2)

In the first article, we described our task sizing based on the types of activities performed to complete it. In this article, we will talk about how we estimate how many hours it will take us to complete the next task with the same parameters as the previous one.

Sep 13, 2022Management
Task Estimation in Gearheart: Activity Types (Part 1)

Story points, dog or fruit scales, T-shirt sizes, dot voting, MAS, and more. There are many different task estimation techniques in Agile. In Gearheart, we went with T-shirt sizes, as we prefer short, iterative cycles to marathon planning sessions.

Dec 7, 2021Management
How to Choose the Type of Mobile App Development: Native Apps vs Web Apps vs Hybrid Apps

What you need to know to choose the right type of app between native vs. hybrid app development or just settle for a web app.

Oct 28, 2021Management
8 Qualities of a Good Developer for Your Software Engineering Project

Consider these core qualities of a good software developer when hiring an outsourcing team for your project. These characteristics are the keys to good work.

Mar 6, 2010TechnologyManagement
Supplementing settings in settings_local

For local project settings, I use old trick with settings_local file:try:from settings_local import \*except ImportError:passSo in settings_local.py we can override variables from settings.py. I didn't know how to supplement them. For example how to add line to INSTALLED_APPS without copying whole list.Yesterday I finally understood that I can import settings from settings_local:# settings_local.pyfrom settings import \*INSTALLED_APPS += (# ...)