How to evaluate tasks without the help of developers?

    Despite the fact that in our small company no one pays attention to the deadlines (this is not important for the customer), from time to time I am faced with the need to assess how long it will take to develop this or that functionality or set of tasks. In addition to evaluating methods “by eye” and “with the help of developers”, which often give a large error, I take another simple approach. The approach is to measure the average time taken to complete one task in the past.

    Data collection


    At the end of each month, I do a simple operation for each developer: I save in Excel the number of working hours in a month (production calendar to help) and the number of tasks a person completed per month.

    In the excel file, the average number of working hours for which the employee does one task is immediately calculated. The average is calculated both for the entire observation period and for a specific month so that you can look at the dynamics.

    There, in Excel, the average execution time of one task for the whole team (or several teams, or the whole company) is also calculated. For example, in my team of seven people, the average time to solve one problem is 14 hours.

    There is a small question: what is considered to be the tasks done in a month? After all, there are tasks that were started by the employee in the past (or the year before last) month and completed in this. After a little thought, I decided that I would take into account all the tasks assigned to the employee, which were transferred to the Closed status this month (the Redmine that we use to manage tasks allows us to collect such statistics). This is logical, because in the general statistics for all months, which is actually needed, the specific month of completion is unimportant.

    Application


    To evaluate the time required to develop functionality, it should be divided into tasks. Tasks should be typical for the team size. And then everything is simple:

    T = N * A * k / D ,
    where:
    T - estimate in hours;
    N is the number of tasks;
    A - average time for the team to complete one task in hours;
    k is the uncertainty coefficient;
    D - the number of developers in the team.

    Why do we need k - the coefficient of uncertainty? Despite the fact that A includes typical minor risks on the project (illness, days off, low working capacity due to poor health, etc.), it does not take into account some things that affect the overall execution time of the task list. For example, distracting people to tasks not related to the functionality in question (bugfix of old functionality, urgent tasks). Or, for example, adding new tasks to the functionality: you didn’t think of something or you suddenly had to decompose a large task a little smaller (according to my measurements, we add 30% - 50% of new tasks on the project during the work on the functionality). Initially, I took k = 1 + 0.4 (new tasks) + 0.2 (switching) = 1.6. But as data accumulated, he reduced it to 1.5.

    How does it work in life? Recently, we had to make a new feature on the project. My team was busy, so the director suggested taking the next one with the words "these will write everything to you in a couple of weeks." I was less optimistic and thought that it would take at least a month. After the feature was divided into tasks, just in case I decided to make an assessment. Since I did not have parameters for the new team, I just took the ones that I use for mine and got the guys finish in 2.5 months. This is not as rosy as two weeks or even a month. In the end, everything was ready in 3 months. By the way, based on a task-oriented assessment of the developers themselves, it turned out that they would need about 1.5 months.

    Summary


    As a result, I will give the advantages and limitations of the described method.

    Advantages:
    • Simple and fast - it’s easy to collect statistics, just read the rating. You can even adapt to evaluate in the mind.
    • It takes into account typical minor risks: illness, days off, switching to urgent tasks, etc.
    • Allows you to evaluate the volume of work even before the developers began to evaluate.
    • If there are statistics separately for each person, then you can calculate the score for any teams made up of these developers.

    Limitations:
    • It is necessary to collect statistics, otherwise nothing will be evaluated.
    • It is necessary to select an uncertainty coefficient - k.
    • The tasks collected in statistics and the tasks to be evaluated should be formed in the same way. For example, if one manager prefers to create tasks for no more than 8 hours (if more, then break them into smaller ones), and for another, weekly tasks are the norm, then their tasks cannot be combined in assessment and statistics.
    • Complex and easy tasks should be distributed between developers more or less evenly. If one person constantly gets tasks lasting 1 hour, and the second - 8 hours, then there are distortions in their performance. By the way, this can be used to identify people whom you underload or overload with complex tasks.

    Also popular now: