How Can a PM Set Up Dashboards for Their Projects?

We will look at the example of TFS, which, beginning this year, has been used by all our teams. Previously, we went through different project management systems. We eventually realized that TFS combines almost everything that a developer needs: code repository, and project, build, test, and release management.

There are dashboards that allow you to track the dynamics of teams, the quality of releases, and bug fixes. Some are built into the system by default, while others can be configured manually.

For analytics to be truly useful, it must meet the following conditions:

1. Even before the dashboard, you have already collected this data manually, and the new panel only automates this work.
2. The dashboard describes real processes within the team that are directly related to its effectiveness.
3. Analytics gives you a real understanding of the situation, problems and risks, and does not just show what a good job everyone is doing.
4. Conclusions can be scaled to other teams and projects, so everyone has a single coordinate system.

Now let's talk about the possibilities of TFS.

First, about the default dashboards:

We asked our PMs what data from the basic set they use in their dashboards, and we complied the following list:

• Lead Time. It shows the time it takes for a single task to be completed for an entire process, from creation to closure.
• Cycle Time. It shows the time spent on a development task, from the moment it was taken into work, to the final delivery.
• Quality of deliveries. This is the number of bugs that were introduced, and worked out, during a sprint. When you click on the graph, you can see what these bugs are. The filter allows you to sort them (for example, you can enter "sprint 64" and see everything related to it).

These indicators give a rough idea of how things are going inside the team. As is often the case with basic features, they do not reveal the full potential of analytics. For example, Lead Time seems to be a useful indicator that shows for how long a task has been stuck in the backlog. However, if your developers, as we would do, start tasks several sprints ahead, the value of these numbers turns out to be small. You can set a goal for yourself to bring the Lead Time closer to the duration of a sprint. Yet, that means you adjust your processes to an additional tool – and why do this if everything already works as it is? That is why teams eventually abandon dashboards, which become the fifth wheel in a perfectly moving cart.

On the other hand, in TFS, you can configure additional panels to get analytics in exact way that the PM needs.

The additional dashboards we use

These panels were born from the life itself: previously, for this data, you had to go to different sources, such as Excel registries and work trackers. Now you do not need to spend time on this - just set up the necessary analytics once.

Thus, each PM will have their own set of dashboards that they need. For a general idea of the data you can work with in this way, here are some examples from our own experience:

• Incomplete tasks for the current sprint. It helps you quickly understand what to focus on in order to do everything on time.
• Issues that did not pass the review. This includes work that may fall into the problematic category because the team evaluates the necessary resources too late or incorrectly.
• Unclosed tasks in production. These are the tasks that have already been passed to the customer, but for some reason, remained on the list. For a PM, this is a reason to contact the client and find out if there are any problems with these tasks.
• Tasks that are the release candidates. This data helps PMs make plans and understand when each task will be released. The same metric allows you to check the completeness of a release: if a build differs in composition from the dashboard, you need to look for a failure.
• A high score in a sprint: tasks with more than 40 man-hours of work that clearly require special attention.
• New tasks in an active sprint: it helps to deal with the unmatched work during a sprint.

Each item on this list is a potential risk that a PM should not miss. The analytics window becomes a workplace with which you can start your day. As long as the windows do not turn red, everything is fine.

The effect project analytics have made

• The PM does not need to do anything to understand the state of things in the sprint. Managers have convenient access to the data, for which they previously had to use more than one system.
• If difficulties arise, a special alert warns you in advance. If there is an alarm signal, you can immediately resolve it, before it grows into an actual problem.
• The quality of management has improved. We began to split the PBI into smaller tasks, and have accelerated the releases. The Cycle Time dashboard from the basic set helped us a lot here. You should not abandon the default dashboards completely.
• Not only the PM, but also other team members, use analytics. Everyone speaks the same language, and knows what indicators play an important role for the release. These technologies can be easily scaled, so that the entire company works with the same successful practices.