In the article Setting up a scoreboard for developers I described why and how I developed the dashboard for the development department at NIST. In the last three months I rewrote it from scratch and published the engineering dashboard on Github.

Screenshot of the Dashboard

Why rewriting was necessary

In the original version, the dashboard, which was implemented as a React application, consumed REST APIs directly to load data from data sources, such as Github and Pivotal Tracker. Authentication tokens are required to access these APIs. These were included unencrypted in the JavaScript code. An attacker would have had an easy time with this if he had had access to the dashboard.

Data access from the JavaScript client also has limitations if additional services are to be included. Heroku’s API, for example, prohibits integration in the browser via CORS. The extension of the dashboard would thus be set quite narrow limits.

The third and last reason is the use of API requests. Both Github and Pivotal Trackers have quite generous limits for accessing the REST APIs. However, in the last version several API requests were executed per dashboard display, for example for historical data from completed sprints.

For these reasons I decided to split the application into frontend and backend and move the data access logic to the backend. The backend performs the data access without the client knowing about the authentication tokens, filters the API results for relevant content and caches this data in a MongoDB.

UML diagram

Other changes

Story point distribution

Visually, little has changed in recent months, as the presentation of most key figures works well. One area where I did various experiments was the diagram in the top left corner, which showed the development of the story points over the last sprints. Unfortunately, this diagram caused too much confusion. Our story points are simply not comparable, as we estimate with non-linear points based on the Fibonacci series (0,1,2,3,5,8). For this reason a story with 8 points can have a much larger scope than 8 stories with one point each. In addition, you can also work diligently on bugs, chores or tickets with 0 story points during the whole sprint, but these didn’t have any influence on the display. This works well for developers who are used to dealing with these values. But it’s difficult to explain these numbers to a manager when he’s standing puzzled in front of the dashboard.

Dashboard element

Therefore, I have replaced the history of the story points and replaced it with a detailed representation, which includes the distribution of tickets to the different story point values. The valid story point values (0 to 8) as well as bugs and chores are plotted on the X-axis. The Y-axis represents the number of tickets that belong to the respective story point category. The bars are still colored in sections. The colors represent which part of the tickets of the respective category are planned, started, etc..

New color scheme

I replaced the old color scheme with a new one. How do you like it?

Improvements to list of oldest Pull Requests

The list of Pull Requests shown in the bottom left area received a few improvements as well. I removed the author column and replaced it with tags that have been added to the PR. The second column now contains links to the related ticket in Pivotal Tracker and the PR on Github. And last but not least has the styling been improved so that the table scales much better now.