Dashboards

1. You are here:
2. Engineering
3. Development Department
4. Dev Sub-department
5. Create Stage
6. Engineering Managers
7. Dashboards

On this page

• How are dashboards used in the Create Stage?
• Idle MR Dashboard
• Create Say / Do Dashboard
• Frontend Large MRs Dashboard
• Backend Large MRs Dashboard

How are dashboards used in the Create Stage?

Dashboards are used to identify trends, analyze behaviors, and alert Engineering Managers to possible opportunities for improvement.

Dashboards provide transparency and automation to Engineering Managers. However metrics or dashboards alone don’t always tell the whole story. Engineering Managers use some of their investigation skills to determine what the whole story actually is.

• For example, a particular dashboard might show that an engineer spent 3 weeks on a merge request. Looking at the data alone, one might think the engineer needs to improve on their iteration value. However, the reality could be that the Engineer unexpectedly took 3 weeks off and that is why the merge request has not been worked on.

Idle MR Dashboard

Why do we use this dashboard?

• Results: Unfinished work could possibly be opportunities for iteration or improving results. These idle MRs turn into old code and might need to be refactor when it is finally integrated into the codebase depending on how long it has been idle.
• Collaboration: In some instances, community contributors author merge requests but for some reasons they end up becoming idle. This is a great opportunity to engage with the community about our product, tech stack support or even iteration coaching.

Create Say / Do Dashboard

Why do we use this dashboard?

• Results: This dashboard measures whether or not engineering does what they say they are going to do which directly measures results.
• Collaboration: This dashboard also measures how well we are doing collaborating with our Product Team. The Product Team sees issues labeled as a deliverable as a commimtment to from enginering to Product that this work will be done. The more engineering adheres to their commitments, the more trust and reliability is strengthened between Product and Engineering.

Frontend Large MRs Dashboard

Why do we use this dashboard?

• Iteration: As part of our iteration value, we strive to break work down into small pieces. This board shows that there is frontend work that is very large, either having many files or many lines of code. This dashboard will alert team members to an opportunity to improve iteration!
• Results: Small iterations lead to customers getting product value sooner. They are also easier to revert (if necessary) and result in higher quality reviews.
• Collaboration: Maintainers and Reviewers are more effective reviewing code when the MRs are smaller and submitted in an iterative manner. Reviewing a few files vs. several files of changes allows them to more closely review code.

Backend Large MRs Dashboard

Why do we use this dashboard?

• Iteration: As part of our iteration value, we strive to break work down into small pieces. This board shows that there is backend work that is very large, either having many files or many lines of code. This dashboard will alert team members to an opportunity to improve iteration!
• Results: By identifying large MRs, we can identify opportunities for either individual growth or team process improvements.
• Collaboration: By analyzing large MRs we can possibly reduce the number of large MRs in the future which positively impacts the results for Reviewers and Maintainers.