Sep 13, 2022

Task Estimation in Gearheart: Activity Types (Part 1)

Task Sizes and Activity Types

We agreed on the following task sizes:

  • U - unestimated tasks not yet rated;
  • XS - minor editing, up to 60 minutes;
  • S - 1 to 3 hours;
  • M - 3 to 6 hours;
  • L - 6 to 15 hours;
  • XL - 15 to 50 hours.

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:

  • “requirements” - for writing requirements and tasks description;
  • “management” - for planning and management;
  • “estimation” - for task estimation, made by an assigned developer;
  • “communication” - for calls, discussions related to the task;
  • “development” - directly for development;
  • “testing” - for QA testing;
  • “bug fixing” - applicable if QA reported bugs;
  • “support” - when it's not possible to test the task without having a developer to support a QA;
  • “code review” - for code review.

Reasons to use Activity Types

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:

  • Developers' inattention, caused by short deadlines on the project. Solution: include time for manual testing before transferring a task to a QA into task estimation.
  • Integration bugs appear more and more often. It often happens as a project grows. Solution: cover the developed functionality with automated, unit, and integration tests. Follow SOLID. Follow "Clear code" recommendations, etc.
  • Due to deadlines or the busyness of other specialists, complex tasks can be assigned to developers with lower qualifications (Juniors, Middles). Solution: there might be different ways to deal with this problem, from revising deadlines to hiring more Seniors.

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.

Examples of using

Activity types by project

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.

Screenshot 2021-06-29 at 12.23.40.png
Table Example
Screenshot 2021-06-29 at 11.12.54.png
Chart Example

Activity types by person

This is a report for the same developer for different months. He is our leading developer on the project

Screenshot 2022-09-01 at 16.47.54.png

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:

  1. We can monitor our staff activity during their working day.
  2. We notice problems in the workflow as soon as they arise and take the necessary actions where needed.
  3. We build task estimate predictions more accurately, taking into account the fact that the process of creating a product is not only in its development.

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:

Screenshot 2022-09-12 at 14.43.24.png

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.

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.

Apr 11, 2016Management
How we meet our estimations

One of the things we are proud about is our estimation process. Partners and clients regularly ask how we do those and how we manage to meet our deadlines, so I decided to describe our simple recipe.

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 we can override variables from 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 += (# ...)