Points and Badges


Making a game from a process that is not a game is not an easy task. First, it can be seen as a way of exploitation or an attempt of manipulating people if you do it wrongly.

One of the key concepts is that Gamification works better around tasks that are usually boring or repetitive. I am a developer so I know that fixing old, ugly code is not cool. It is actually painful.

Quboo tries to help creating a process in which fixing legacy code and increase code coverage can be a bit more enjoyable. You can compete with other teams and get “symbolic rewards” every month (a nice t-shirt?).

I like Quboo as a developer because it spices up the process. But I also know other people that feels manipulated by it, that may happen. That should not be a problem since participating in the game should be optional. In any case, try to avoid making Quboo a serious topic: do not link it to company goals, do not use it for team/personal performance evaluation, do not scrum-ize it :slightly_smiling_face:.

It is important that, if you introduce this game in your organization, you explain it honestly: what you want to achieve and how to play. There will be people who like it and people who do not. Whatever the result is, feel free to share the feedback with me, I am really interested.

Take into account that the game -at this point- is only using Points, Badges and Leaderboards as Gamification tools. Even though these elements work, that is an oversimplification of how Gamification works. Hopefully, with your help, I can make it even better :wink:.

The Goal

Quboo is designed to improve Legacy Code and help you pay your technical debt. The idea is that you fix potential errors and bad practices that are making your code difficult to maintain. Those are tracked by Sonar, and that is why the game uses it as a source of information.

Defining a Legacy Date

You play Quboo only with old issues. Otherwise, it will be easy to score: you can fix your own bad practices as you introduce them.

Defining what is Old Code (or Legacy Code) can be simple: just take six months ago. Or you can base that date on something more meaningful for your organization: a previous release, for example. You could also set it to the first day on which you deploy the game.

Combining it with Gates

While you fix old code smells do not forget the new ones. Set a Quality Gate in Sonar and remember to tune it every now and then. If you got some improvement on Code Quality, you can set the bar higher!


The game is simple: if you fix a Sonar Issue that was created before the Legacy Date, you get points, and so does your team. The score you get is proportional to the amount of debt you are paying (calculated by Sonar).

If you want to make sure you get the score for the issues you resolve, you need to assign them to you using the Sonar Web interface before you resolve them.

Assigning issues in Sonar


Badges are just extra score - and a nice status.

  • Early Bird. Players who solve issues before a given date will get this badge. This is to encourage people to participate.
  • Unit Tester - Ranks. These badges are related to the Unit Test Coverage and there are different ranks defined. The more tests you fix, the more you score.