Setting Up A Scoreboard For Developers

4 minute read

Anyone who is enthusiastic about football, tennis or any other sport knows that the current score of every match is always clearly displayed on a large blackboard. If a team scores a point, the score on the blackboard changes instantly. On the one hand, the blackboard serves the fans, who can judge the action at a glance, even if they were careless for a moment and could not follow the game. On the other hand, the blackboard is an important instrument for the players and their coaches. They can always see what the current situation is like and can adapt their tactics accordingly.

Scoreboard of the NIST development team

If a concept works well in popular sports, it can’t be so bad for a small development team. So I suggested to the development team at NIST that we introduce such a scoreboard for our key KPIs. At the monthly meeting of the development department, we then discussed which KPIs we wanted to measure and display on the board and agreed to use

  • the number of story poins we implement per sprint
  • the number of accepted stories per sprint - which includes bugs and chores
  • the number of bugs resolved per sprint
  • the time that elapses between the recording and release of a patch for errors
  • the time that elapses between submission and acceptance of pull requests

The selection of a dashboard service that can connect to our tools (Github, Heroku, and Pivotal Tracker) and graphically process the desired numbers was unfortunately more difficult than expected. Geckoboard was very promising in the beginning, but the available diagrams were not sufficient. For this reason I decided to implement a board with JavaScript and React.

A first draft of the scoreboard app

Since we work according to Kanban and not strictly according to Scrum, a burndown chart didn’t make much sense in my opinion. That’s why I chose a bar chart to compare the results of the current sprint with previous results. The donut chart to the right of it shows the progress of the current sprint.

In addition to the agreed points, I implemented some enhancements during the development of the dashboard. In a table the open pull requests are sorted by age. Next to that table is a representation of the open pull requests per application. Both representations should encourage the participating developers not to put open PRs of their colleagues aside for a long time.

Short-term effects

The new display of the team’s work results had a positive effect on the team’s performance even at short notice. The team members dealt with the board, the measuring points used and the performance of the team. It seems as if this conscious consideration of one’s own work results has already led to a slight improvement. I plan to observe this trend for a few more weeks and introduce some small positive incentives. This could, for example, be a clear praise of the team for great results or perhaps I’ll bring some gummy bears when certain thresholds are reached.

Avoiding possible negative effects

Since the scoreboard is clearly visible to everyone, it automatically creates a certain pressure on the members of the team. Of course no member of the teams wants to be responsible for a possible worse performance of the team or decreasing personal results. On the one hand, such pressure can lead to the elimination of bad habits. On the other hand, pressure can also have a significant negative impact on the team. For this reason, we have been guided by our principle when selecting KPIs and presenting them: what counts is the success of the team. We therefore evaluate our KPIs only at team level and not for individual team members.

We also do not focus on individual KPIs, but always look at the combination of different key figures and the connection with any external factors. If management only uses a single KPI, such as the story points implemented per sprint, for the evaluation, there is no incentive for senior developers, for example, to spend more time training juniors. Good code reviews, necessary restructuring of the code, etc. need their time, which is why they should not be neglected.

Next Steps

Since the board works well for us, I’d like to make some more improvements to it. These include in particular:

  • Replace the bar chart in the upper left corner with a line chart which visualizes a longer period of time. I want to make the visualized time period configurable.
  • Better assignment of the colors that are used to show the states of the tickets in the donut-diagram above in the middle. Some of my team members have described the assignment as unintuitive.
  • Linking the pull requests in the table below right with the detail pages on github.
  • Link the bar chart in the middle with the repository overview on github.
  • Extension of the diagram at the top in the middle. If you click on the diagram, a detailed representation of the tickets with the respective status would be helpful.
  • Extension of the lifetime diagrams for bugs and PRs: If you click on the diagram, a detailed representation of the pull requests / bugs would be helpful.