Why you shouldn't waste every ones time?

Work efficiency is one of the most important factors in the world of services providers. This is especially important for software development companies, as costs of maintaining employees is a main expense in this business.

My goal is to show you how much you lose because of the lack of task estimation practice in your team's ticket system. I promise that I'll try not to sound like a personal coach ?? Of course this can also apply to your business even if you are not from the IT sector.

There are individuals who don't run any ticket system saying that this is unnecessary micro management. This management is an inadvisable of course, but you do that only if you create a ticket like "Write an email to XYZ, ask him about a, b, c and include information about 1, 2, 3". To make ticketing system a reasonable tool you should describe what's the problem and what need to be done. You should avoid writing how it should be done. If you would do task faster compared to time spent on creating and reviewing ticket assigned to somebody else then just do it on your own. If you don't have a ticket system, then just set up one.

So let's say that you already have a system to assign tasks to your team. You are about to sign the contract for a new project, however before that you need to estimate its cost. Fortunately there are more and more companies that hire programmers having in mind that Agile approach will be better for them. Anyway it's expected that your client would like to know how much your services cost in the discussed scope. How to perform cost estimation then? You ask developers for their hours estimation, you add some risk, you calculate it by the rate you have and it ends with the price estimation.

It's okay that you first asked the developers for their estimation of the entire project, but what's wrong with such approach? First, you don't know how much the particular feature will cost and what's more important, your client also doesn't know that! People like to know what's included in the price. Let's say that somebody would like to change the scope of the project. Some feature will be removed and some other added. As you don't know how the particular feature was initially estimated, nobody knows how much you should lower the price. You need to ask developers again.

Imagine how much it would be easier to estimate time for each task separately than for the whole project. To make such estimation accurate you and the dev team can take a look at older projects and check how much time particular functionality took to be implemented. Estimation for the new feature will no longer be like guessing. It will be solid.

Is there anything else wrong? Yes, you added the risk to the whole project and not to every feature. As an effect, the chance of going out of the budget increases. Try to do that next time and check how the risk will differ.

Okay, but what else can go wrong if your team doesn't have estimated tasks? First, you lose the track of progress in the project. How do you know that everything is going according to the schedule if you don't know how much you've done and how much left? This is dangerous if you have fixed deadlines and tasks estimation will definitely help you.

The next problem occurred in my team before introducing estimation for issues in tickets systems. We simply didn't know how much we could plan for the next week. Of course we had a feeling what we are capable to do, but now it corresponds to reality to a greater extent.

Okay, so after listing bright sides of tasks estimation and possible threats coming from not using this practice in work, I need to admit that tasks estimation has drawbacks. The most important thing is the pressure that is put on the programmers if the tasks are estimated by hours. Stress is what I was feeling working as the developer and in the long term it's not advisable to have stressed employees.

Fortunately, I have a solution for this. The practice I propose is to migrate your team to size-based estimations. Wait... What does "size" mean here? It means that the task can be estimated as small (S), medium (M), large (L) and extra large (XL). Exactly like with the clothes you can also add another sizes like XS or XXL if there is such a need. In my team we use S, M, L, and XL only.

You only need to establish what does it mean that the task is small or large using experience you got from previous projects. You should care not only about hours spent on the tasks, but also about their complexity. As you have your definition of sizes you can now translate to the hours as finally, from a business perspective, you still need to know how much will the project cost for the client. They will probably not accept that the project is just large and you'll need to give them the price range. To do that you need to have these sizes translated into hours, but never show these translations to the developers. If you do that, they will calculate hours on their own, and the main advantage of size-based estimations (taking pressure off) will disappear.

I'll not go into further details, but if you want to know more about size-based estimates I recommend to read this article:

Now you should see why I care about the tasks estimates, and what approach I use for this purpose. I'm open for discussion, so if you have any thoughts share them in the comment section. :)