## 5 Experimental Evaluation
### Experiment Design  
The experiment clarified the effectiveness of our method compared with a traditional method. Subjects were asked to comprehend the target project, which is the same as that of the aforementioned case study. (1) Subjects  
The experiment involved 28 participants. All subjects were graduates and undergraduates recruited from the same university but with different majors. As a prerequisite, we confirmed that all subjects had some basic programming experience in advance. Subjects were divided into two groups: 14 subjects \(S_{1}\)-\(S_{14}\) were in the experimental group \(G_{E}\), and the other 14 subjects \(S_{15}\)-\(S_{28}\) were in the control group \(G_{C}\). (2) Methods and inputs  
The traditional method was a non-tool-assisted exploration of the tickets. No specific tool was given to the subjects. As inputs, both the experimental and control groups received the document explaining the objective and the background of the target project, and the set of 111 ticket descriptions exported from the ITS in the form of Excel spreadsheets as source documents. We confirmed that practitioners often tried to understand implemented features without any specific tool supports by conducting preliminary interviews in the case study company. Furthermore, since we assumed that there would be no significant difference between comprehending implemented features one by one directly on the ITS and that on the exported spreadsheets, we decided to compare our method with the non-tool-assisted exploration, which utilized the spreadsheets only. We plan to conduct further comparative evaluation against other tool-supported methods as our future work. Each ticket description contained its title, detailed description, date of its creation, and date of its last revision. The date of the last revision was regarded as its completion date. The ticket set was exactly the same as that in the case study. Only group \(G_{E}\) received two heatmaps to comprehend the activeness of tickets and features: the lifetime heatmap of the ticket categories (Figure 8) and the keyword heatmap of the ticket categories (Figure 10). (3) Tasks  
Subjects were asked to perform four tasks: \(A_{L1}\), \(A_{L2}\), \(A_{F1}\) and \(A_{F2}\). \(A_{L1}\) and \(A_{L2}\) focused on the comprehension of activeness of ticket categories with time, while \(A_{F1}\) and \(A_{F2}\) were about comprehension of activeness of features. The subjects in GE were instructed to refer to the heatmaps and the set of tickets, while the GC subjects referred to the set of tickets only. * \(A_{L1}\) asked the participants to identify up to three specific weeks where the development was 'active'. Here, 'active' means a busy development state with many unresolved tickets compared with the last time frame. Subjects received 0, 33, 66, or 100 points if they identified zero, one, two, or three correct weeks, respectively. * \(A_{L2}\) asked the participants to identify up to three specific weeks where the development was inactive compared with other weeks. Here, 'inactive' means a less busy development state with few unresolved tickets compared with the last time frame. Only 2 of the 14 weeks met this definition. Subjects received 0, 50, or 100 points if they identified zero, one, or two correct weeks, respectively. * \(A_{F1}\) asked the participants to identify up to five specific'stable' features compared with other features. Here,'stable' means that most of tickets related to the feature were unresolved even in the latter half of the development period. Four of 13 features met this definition. Each subject received 0, 25, 50, 75, or 100 points if the subject identified zero, one, two, three, or four correct features, respectively. (4) Experimental procedure  
In January 2021, both group subjects participated in a 60 min experiment composed of three consecutive sessions. During all sessions, subjects were not allowed to discuss or communicate with each other. * The first session took 10 min.