Hello, my name is Gabriel Franceschini, today we are going to talk about the impacts and difficulties of checking or analyzing your game development project through indicators, metrics, and KPI.
Introduction
As a producer or as a manager, it’s common to be in touch with several projects at the same time. Usually, we can use our expertise, immersion, and assimilation to understand and direct the project or product in the most assertive way.
Obtaining control over a game development project is already a challenge to overcome.
This kind of project has a more abstract direction, it’s not just working with data, it’s deeper, as we talk about in the articles before, it has some particularities and obstacles that don’t exist in other kinds of projects.
Game development is different from other types of development
First, it’s important to remember that game development production is different from developing other types of software, like software that only works with data or specific hardware applications.
These kinds of software are developed with a progressive structure, for a long time period, even after the release date, the production keeps the development team.
While at game development, usually projects have an end date and the team need to be integrated into other projects.
Developers vision vs stakeholder’s vision
As game developers, we are trying to build something concrete from abstract ideas, and sometimes it’s hard to have a clear idea as the mastermind behind the game concept.
As well is normal that different production areas from the game development have different options about efforts x results.
It’s usual that clients, producers, and other stakeholders that don’t necessarily have the technical knowledge or game development experience, feel in a situation they aren’t safe about the progression, results, and the path the project is going.
Metrics can lie
Depend on how and when the application of this KPI or metric. It’s possible that doesn’t reflect the real production performance of the team. Once this information reflects only the state that this performance was in the application time frame.
It’s unclear to know the product performance before any measure can be analyzed and compared.
As well at the moment that we start to measure these KPIs the team behaviour change, and that influence future analyzes from the same metric.
4 types of KPI
Now let’s see some types of metrics that are already used in different kinds of TI companies, and how the metrics can influence your game development.
1 – Number of code lines
With this type of metric, the progression is based on the number of code lines written by the programmer. Particularly, I was a programmer, so I do not recommend this metric.
It’s easy to say that amount of code lines don’t reflect the progress or the quality of these codes. So, it doesn’t reflect the amount of progression that your project resulted in.
This can lead the team to write without control, generating heavier software, ineffective solutions, stress, and not sum the project speed. Probably would slow it.
2 – Story points
With Story Points, we are focusing more on effectiveness and complexity progression.
In this method, mechanics, features and tasks will have points.
These points are set in a planning meeting with the poker planning methodology or something like that.
The team can compare the difficulties and set a fair amount of points.
From this step, it’s possible to have control over the amount and the period that these tasks are been completed and the story points reflect a more realistic project progression.
3 – Number of hours
I should say that this type of metric is one of the most popular ones. Because it’s easy to assimilate the information. And can simplify the communication between stakeholders and production.
It has the same premise as the story points, in these cases, the amount of hours is calculated for each task, again in a planning meeting.
After that, it’s possible to check the amount of time spent x estimative x progression.
4 – Burndown Chart
The third one doesn’t necessarily need to have the number of hours of the difficulties from the project. But it’s focused on the effective delivery date for each task.
It’s this type of control, each task or feature has a due date. As time passes the number of tasks in the backlog is finished until everything is completed in the set time frame.
Making it possible to measure if the tasks are been delivered on the planned date and how this impacts the future of the next milestones.
The hardest boss
The biggest villain or problem with all the metrics is new work or re-work.
New tasks, problems, bugs, new directions or ideas can heavily impact the game development, no matter what kind of KPI it uses.
These new configurations can have extreme changes in a project based on abstract ideas and coding.
In the future, we can discuss how new types of metrics based in a progressive system and social aspects can help new kinds of projects with new kinds of teams around the world in the 21 century.
