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.
Activity types by person
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:
- We can monitor our staff activity during their working day.
- We notice problems in the workflow as soon as they arise and take the necessary actions where needed.
- 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:
Subscribe for the news and updates
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.
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.
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.
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.
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 += (# ...)