Employers require software engineers to work in teams when developing software systems. It is therefore important for graduates to have experienced teamwork before they enter the job market. We describe an experiential learning exercise that we designed to teach the software engineering process in conjunction with teamwork skills. The underlying teaching strategy applied in the exercise maximises risks in order to provide maximal experiential learning opportunities. The students are expected to work in fairly large, yet short-lived, instructor-assigned teams to complete software engineering tasks. After undergoing the exercise our students form self-selected teams for their capstone projects. In this article, we determine and report on the influence the teaching exercise had on the formation of teams for the capstone project. By analysing data provided by the students through regular peer reviews we gain insight into the team dynamics as well as to what extent the members contributed to the team effort. We develop and present a graphical model of a capstone project team which highlights participation of individuals during the teaching exercise. The participatory history of the members is visualised using segmented concentric rings. We consider how this visualisation can aid the identification of capstone project teams that are at risk. In our experience the composition of the team and the behaviour of other members in the team may have a marked impact on the behaviour of each individual in the team. We established a team classification in order to model information about teams. We use a statistical clustering method to classify teams. For this we use team profiles that are based on the participatory levels of its members. The team types that emerge from the clustering are used to derive migration models. When we consider migration, we build spring models to visualise the teams through which individuals migrate. We colour code the teams to characterise them according to the team types that were identified during the cluster classification of the teams. Owing to the complexity of the resulting model, only migrations for capstone team members who have worked together during the exercise or for solitary capstone team members are modelled. These models support the identification of areas of interest that warrant further investigation. To conclude, we present our observations from the analysis of team compositions, team types, and team migrations and provide directions for future work and collaborations.