How to evaluate tasks without the help of developers?
Despite the fact that in our small company no one pays attention to the deadlines (it does not matter to the customer), I occasionally encounter the need to estimate how much time it will take to develop a particular functionality or set of tasks. In addition to evaluating the methods “by eye” and “with the help of developers”, which often give a big margin of error, I use one more simple approach. The approach is to measure the average time to complete one task in the past.
At the end of each month, I do a simple operation for each developer: I keep in Excel the number of working hours in a month (production calendar to help) and the number of tasks made by a person in a month.
In the Excel file, the average number of working hours for which the employee performs 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.
The Excel also calculates the average execution time of one task for the whole team (or several teams, or the entire company). For example, in my team of seven people, the average time to solve one task is 14 hours.
')
There is a small question: what should be considered as tasks done in a month? After all, there are tasks that were started by an employee in the past (or before last) month and completed in this. A little thought, I decided that I would take into account all the tasks assigned to the employee, which were transferred to Closed status this month (the Redmine, which 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, a specific month of completion is not important.
To estimate the time required to develop a functionality, it must be broken down into tasks. Tasks should be typical for team size. And then everything is simple:
T = N * A * k / D ,
Where:
T - score in hours;
N is the number of tasks;
A is the average time for a team to complete one task in hours;
k is the uncertainty coefficient;
D - the number of developers in the team.
What is k for - uncertainty coefficient? Although A includes typical minor risks on a project (illness, time off, poor performance due to poor health, etc.), it does not take into account certain things that affect the overall time of the task list. For example, distraction of people to tasks not related to the functionality in question (bugfix of the old functionality, urgent tasks). Or, for example, adding new tasks to the functionality: something was not thought out or had to suddenly decompose a large task into several smaller ones (according to my measurements, we have 30% - 50% of new tasks added to the project during the work on the functionality). Initially, I took k = 1 + 0.4 (new tasks) + 0.2 (toggle) = 1.6. But with the accumulation of data 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 offered to take 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 broken down into tasks, I decided to make an assessment just in case. Since I did not have parameters for the new team, I just took the ones I use for my own and got the guys to finish in 2.5 months. This is not so rosy as two weeks or even a month. In the end, everything was ready in 3 months. By the way, based on the assessment of the developers themselves, it turned out that they would need about 1.5 months.
As a summary, I will give the advantages and limitations of the method described.
Advantages:
Limitations:
Data collection
At the end of each month, I do a simple operation for each developer: I keep in Excel the number of working hours in a month (production calendar to help) and the number of tasks made by a person in a month.
In the Excel file, the average number of working hours for which the employee performs 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.
The Excel also calculates the average execution time of one task for the whole team (or several teams, or the entire company). For example, in my team of seven people, the average time to solve one task is 14 hours.
')
There is a small question: what should be considered as tasks done in a month? After all, there are tasks that were started by an employee in the past (or before last) month and completed in this. A little thought, I decided that I would take into account all the tasks assigned to the employee, which were transferred to Closed status this month (the Redmine, which 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, a specific month of completion is not important.
Application
To estimate the time required to develop a functionality, it must be broken down into tasks. Tasks should be typical for team size. And then everything is simple:
T = N * A * k / D ,
Where:
T - score in hours;
N is the number of tasks;
A is the average time for a team to complete one task in hours;
k is the uncertainty coefficient;
D - the number of developers in the team.
What is k for - uncertainty coefficient? Although A includes typical minor risks on a project (illness, time off, poor performance due to poor health, etc.), it does not take into account certain things that affect the overall time of the task list. For example, distraction of people to tasks not related to the functionality in question (bugfix of the old functionality, urgent tasks). Or, for example, adding new tasks to the functionality: something was not thought out or had to suddenly decompose a large task into several smaller ones (according to my measurements, we have 30% - 50% of new tasks added to the project during the work on the functionality). Initially, I took k = 1 + 0.4 (new tasks) + 0.2 (toggle) = 1.6. But with the accumulation of data 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 offered to take 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 broken down into tasks, I decided to make an assessment just in case. Since I did not have parameters for the new team, I just took the ones I use for my own and got the guys to finish in 2.5 months. This is not so rosy as two weeks or even a month. In the end, everything was ready in 3 months. By the way, based on the assessment of the developers themselves, it turned out that they would need about 1.5 months.
Results
As a summary, I will give the advantages and limitations of the method described.
Advantages:
- Simple and fast - it is easy to collect statistics, just count it. You can even adapt to evaluate in the mind.
- Takes into account typical minor risks: diseases, time off, switching to urgent tasks, etc.
- Allows you to estimate the amount of work before the developers have started to evaluate.
- If there are statistics separately for each person, then you can calculate the assessment for any teams made up of these developers.
Limitations:
- Statistics are required, otherwise it will not work.
- The selection of uncertainty factor is necessary - k.
- Tasks collected in statistics and 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 into smaller ones), and for another weekly tasks are the norm, then their tasks cannot be combined in assessment and statistics.
- Difficult and easy tasks should be distributed between developers more or less evenly. If one person is constantly given tasks for 1 hour and the second is 8 hours, then there are distortions in their performance. By the way, this can be used by identifying people whom you underload or overload with complex tasks.
Source: https://habr.com/ru/post/296852/
All Articles