We agreed on the following task sizes:
Later we noticed that the task size includes not only development itself but also other activities. These activities are still just as important as development since you can't complete a task without performing them. To see the whole process in detail, as well as to be able to make accurate predictions on task sizes, we added another variable here - Activity types.
Working on a task may include:
Also, there were other reasons for adding Activity types. Because we are an entirely remote company, we wanted to clearly understand what our team is performing. We also wanted to be able to spot problems during development as soon as they appeared. I want to give a couple of examples here:
You might notice that the share of "communication" has increased.
One possible reason could be unclear or too short requirements. A developer often has to contact a business analyst to clarify the requirements for a task. One possible solution here could be to create a checklist of requirements (must-have) for the BA so that he does not forget to include all the details in the task description. In addition, you can create a couple of task description templates, showing examples of a good task description. By reducing the time spent communicating, you will get your team to complete more tasks in the same amount of time.
"Bug fixing" share increase. Many possible reasons could cause this change. Here are only some of them with solution examples:
The main idea here is that when you have an indicator to look at, you are more likely to understand the essence of the problem and find the most effective solution to fix it.
With the monthly "Activity types by project" report, you can track the workflow of your entire team. We recommend comparing monthly data with the previous month's data.
Below is an example of a monthly report for one of our projects.
This is a report for the same developer for different months. He is our leading developer on the project
Here we see that in August he spent more time on process management, but not on product development. Also, he spent a lot of time on communication. The share of "development" activity in August amounted to only 18.8%, and this is a reason to take a closer look at it. In March, he spent nearly a third of his time testing. If we didn't know that during these months we had a global regression of the entire project, this could become a problem. Since we are aware of regression, there is no cause for concern.
To sum up, after dividing our task estimates into activity types, we’ve got three advantages:
The methodology of our task estimation predictions will be described in the Task Estimation in Gearheart: Activity Types (Part 2) article. But I want to add a small teaser at this point: as a result, you will get the following table:
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 += (# ...)
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.