1. Motivation
Iterative product development demands rapid decisions, clear communication and a shared understanding of how a system evolves over time. In practice, however, these expectations collide with the reality of short cycles, shifting requirements and frequent design changes (Reference Jarratt, Eckert, Caldwell and ClarksonJarratt et al., 2011). Reviews are meant to bridge past decisions and future actions (Reference Ankele, Duehr, Albers and BursacAnkele et al., 2023), yet teams often enter them without a structured overview of what exactly changed, why it changed and how these changes influence subsequent planning. As a result, feedback is captured inconsistently, dependencies remain unclear and the transition from review insights to actionable next steps becomes opaque.
Visual representations are widely used across engineering, from sketches and CAD models to task boards and sprint backlogs. These artefacts offer valuable entry points for discussion, but they typically cover isolated aspects of the process: geometric detail, task status or functional logic (Reference Chandrasegaran, Ramani, Sriram, Horváth, Bernard, Harik and GaoChandrasegaran et al., 2013). What is missing is a product-centered visualization that connects retrospective engineering changes and deviations, real-time review communication and prospective planning in a single coherent flow. Prior research highlights the importance of shared mental models and boundary objects in engineering collaboration (Reference Mathieu, Heffner, Goodwin, Salas and Cannon-BowersMathieu et al., 2000), (Reference LuoLuo, 2009), yet it remains largely unexplored how a visualization can be designed to systematically support all three perspectives within an iterative development cycle.
This paper introduces a visualization method that addresses this gap. The approach consists of three interconnected representations: a retrospective view that highlights engineering changes and deviations between development stages, an interactive review view that captures feedback directly on the product architecture and a prospective view that translates review insights into clear, product-anchored planning steps. Together, these visualizations create a continuous thread from past decisions to future actions, enabling teams to discuss changes more clearly, anchor feedback more precisely and plan the next sprint more transparently.
The method is developed and exemplarily applied within the Live-Lab Generational Sheet-Metal Development. Its application shows how product-centered visualization can strengthen communication during reviews, reduce ambiguity in decision-making and provide a more traceable foundation for sprint planning. The findings underline the potential of tailored visualizations to support both retrospective and prospective reasoning, and to enhance collaborative understanding in iterative engineering processes.
2. Theoretical background
The development of products is becoming increasingly demanding due to rising internal and external challenges (Reference Lindemann, Maurer and BraunLindemann et al., 2009). Higher cost pressure, changing customer requirements, and shorter cycles make robust product development processes necessary. This results in the implementation of agile methods in the field of product development (Reference Strube, Stieber and PuchanStrube et al., 2018). The quality of communication is of critical importance for the success of the agile development project (Reference Mateescu, Kropp, Greiwe, Zahn and BurkhardMateescu et al., 2015). Visualization methods can serve as an effective means of supporting this communication. In the present work, a visualization method for use in an agile product development process is developed.
2.1. Agile development processes
Based on the guidelines of the Agile Manifesto, responding to change should be preferred in comparison to strict processes and extensive documentation (Reference Beck, Beedle, van Bennekum, Cockburn, Cunningham, Fowler, Grenning, Highsmith, Hunt, Jeffries, Kern, Marick, Martin, Mellor, Schwaber, Sutherland and ThomasBeck, K. et al., 2001). In Scrum, the most common framework, the development steps are carried out in sprints. These are time-limited cycles that usually last between one to four weeks. The results are presented at the end of each sprint in a review. During the review, the developed product or subproduct is presented to the stakeholders. This process aims to collect feedback for the coming iterations, represented by the following sprints. Based on the obtained feedback, collaborative formulation and prioritization of the new requirements takes place during the sprint planning. The requirements are then collected in the Product Backlog (Reference Schwaber, Sutherland, Casanave, Miller, Patel and HollowellSchwaber, 1997). However, a large Product Backlog can result in a confusing or unclear representation.
The central principles of agile development are openness, transparency, and continuous communication between all those involved. These serve to continuously align knowledge and ensure a common understanding of the project progress. To support this process, agile environments often incorporate visual artifacts such as task boards, burndown charts, or backlog representations to allow transparency regarding tasks, dependencies, and progress. Despite these established visualizations, practice shows that context-specific technical connections, variants, and decision (Reference CarlileCarlile, 2002) car rationales are often not clearly documented or communicated in an understandable way. To ensure efficient collaborative work, it is vital to ensure a common understanding of the product being developed, also known as the Shared Mental Model (SMM) (Reference Mathieu, Heffner, Goodwin, Salas and Cannon-BowersMathieu et al., 2000). For the creation of such a common understanding, visual models are primarily used, as they function as boundary objects between people with different interests and levels of experience, thereby easing the exchange regarding shared content. They create a common reference point on which different viewpoints can be combined and aligned (Reference Star and GriesemerStar & Griesemer, 1989).
Especially in interdisciplinary development environments, in which mechanical, electrical, and software-related aspects are brought together, such visual models are vital to synchronize knowledge and prevent misunderstandings (Reference CarlileCarlile, 2002; Reference Förster, Koldewey, Bernijazov, Dumitrescu and BursacFörster et al., 2025). From this arises the need to develop visualization methods that support both retrospective communication in reviews as well as prospective planning steps. They should promote consistent common understanding within the team and thus improve the quality of decisions made in the development process.
2.2. Visualization as a tool in product development
Visualizations are simplified, abstract, and static graphical representations of products, their structures, characteristics, and behaviors, which support the product development process (Reference Gebhardt and KrauseGebhardt & Krause, 2016). In the product development context, they refer to the targeted depiction of technical, functional, or process-related relationships of a product. They serve to make knowledge about the product and its creation visible, verifiable, and accessible to different stakeholders.
Visualizations serve in product development as common reference points between different stakeholders and disciplines. They function, in the sense of Shared Mental Models (Reference Mathieu, Heffner, Goodwin, Salas and Cannon-BowersMathieu et al., 2000), as the basis of a shared product understanding and can also be understood as boundary objects that connect different perspectives without being fully unified. In this way, they support the translation of knowledge across disciplinary and organizational boundaries (Reference CarlileCarlile, 2002).
The classical forms of visualization include technical drawings, which have served as a central communication basis between design, manufacturing, and assembly. They follow standardized visualization rules (e.g., according to DIN ISO 128) and allow precise and unambiguous communication of geometrical and functional product information.
Complementary to that, sketches, CAD models, exploded views, functional and cause and effect diagrams, process models, or variant trees are used. Sketches and CAD models support intuitive understanding and quick idea generation, while structured models such as effect surface pairs, functional structures, or process diagrams make systematic relationships visible. Variant trees or configuration models serve to support the traceability of product families and change states (Reference Bender, Gericke, Pahl and BeitzBender et al., 2021).
All these representations fulfill the same core purpose: they reduce complexity, create transparency, formalize information, and enable a common knowledge base. By visually anchoring abstract or disciplinary information, they promote discussion, decision-making, and learning processes within the team. Visualizations thus become mediating artifacts that can be used to link individual knowledge of the people involved and provide a common language and knowledge base for product development (Reference Maier, Eckert and ClarksonMaier et al., 2005).
While Product Lifecycle Management (PLM) systems are established standards for managing product data and version control, they primarily rely on list-based or tree-structure representations. These tools excel at data integrity but often lack the intuitive, product-centered visual layer required for rapid, interdisciplinary communication in Agile reviews. Unlike complex PLM interfaces, which require expert knowledge, simplified visual boundary objects are needed to allow all stakeholders—regardless of their software proficiency—to instantly grasp changes and deviations directly on the product geometry.
2.3. Data collection and research in GSD - Generational Sheet-Metal Development
The Live-Lab Generational Sheet-Metal Development (GSD) at Hamburg University of Technology, is a master’s course in Mechanical Engineering. As part of the project, students experience an entire Agile product development process, using the example of a top-heat sheet-metal grill, from start to finish. This process is divided into sprints, and the interim status of product development is presented to stakeholders in reviews between each sprint. These reviews provide a basis for reflection and quality assurance with regard to the manufacturability of the developed product, for example, and inform the planning of the next sprint (Reference Bursac, Krause, Batora and RitzerBursac et al., 2023).
As a live-lab GSD is used as a data collection research environment for product development processes, on engineering changes as well as unplanned engineering deviations (EC&Ds). With the help of collected planning, process and realization data, in form of CAD-files, recordings or whiteboards, it is possible to identify connections retrospectively and investigate discrepancies between planning and implementation (Reference Kull, Schlegel, Förster, Albers and BursacKull et al., 2025).
3. Method
According to Reference Maier and LangerMaier and Langer (2011), engineering changes in the process account for almost a third of R&D funds in engineering companies. These findings show that structured engineering change management, particularly through early detection and traceability of engineering changes and deviations (EC&Ds), can contribute significantly to increasing efficiency. However, EC&Ds are not only inevitable, but also difficult to communicate and document – especially in iterative and agile development processes. Reviews and sprint planning must reflect on past decisions and EC&Ds as well as plan future steps. Often, there is a lack of suitable product-related visualizations that make development statuses comparable and establish a connection to the real product. The consequences are gaps in understanding, unclear responsibilities and difficulties in knowledge transfer. Therefore, the aim of this thesis is to develop a product-related visualization method for use in reviews and sprint planning in the development process, to support retrospective communication of EC&Ds with stakeholders, as well as knowledge storage and prospective planning with team members. To attain the research objective, the DRM – Design Research Methodology by Reference Blessing and ChakrabartiBlessing and Chakrabarti (2009) is applied. The approach is based on the three phases of DRM: Descriptive Study I, Prescriptive Study, and Descriptive Study II.
As part of the Descriptive Study I, requirements for such a visualization method are derived. For this purpose, challenges that appeared within reviews during the problem-based course GSD are analyzed. Hereby, the following research question is to be answered:
What challenges exist in a development process with regard to the retrospective communication of engineering changes and deviations in reviews and the prospective documentation of the next steps in sprint planning, and what requirements arise from this for an appropriate visualization method?
In the prescriptive study, a visualization method is developed that corresponds to the requirements set and thus solves the challenges identified in connection with reviews. The following research question is to be answered:
How can a visualization method be designed that supports the development process, both in the retrospective communication of engineering changes and deviations, as well as in prospective planning of reviews and sprint plannings?
As a second descriptive study, the visualization method developed will be applied in development processes both retrospectively and in parallel with implementation. The following research question is to be answered:
Is the visualization method applicable in the product development process, and does it support both retrospective communication of engineering changes and deviations as well as prospective planning when used in a product development process?
Phases, tasks, and results of the work based on the Design Research Methodology (DRM) (Reference Blessing and ChakrabartiBlessing & Chakrabarti, 2009)
4. Results
4.1. Observation of challenges and derivation of requirements for the visualization method
When conducting the GSD course, difficulties are encountered with regard to the preparation, implementation, and follow-up of the reviews. On the one hand, communication of EC&Ds during meetings remains abstract. On the other hand, there are problems with recording new information in the reviews, which leads to problems in subsequent planning. These difficulties indicate that there is a lack of a suitable method to support retrospective preparation, implementation of the reviews, and prospective follow-up.
4.1.1. Observed challenges
It is apparent that the teams lack structured preparation for the reviews. Development decisions and engineering changes and deviations (EC&Ds) are not specifically recapitulated. This means that there is no common basis for discussion within the team or for the reviewer (H1) . On the one hand, this makes it difficult to inform the reviewers about the decisions that have been made and, on the other hand, to focus on the essential EC&Ds where feedback is most needed. Therefore, there is a lack of a method that supports systematic recapitulation and makes the development history visible and thus comprehensible, to facilitate the start of the review.
The meetings then proceed in an unstructured manner and focus on spontaneous questions (H2) or individual aspects without specifically addressing overarching development decisions. In addition, there is a lack of visual support to illustrate correlations, interfaces, or overall contexts. This also makes it difficult for developers to clearly assign feedback to the relevant components (H3) . The results are often recorded in the form of bullet points in a list. Consequently, it is difficult to clearly locate them on the product, and there is often not enough time to establish the necessary links to the product.
This demonstrates that there is a lack of a common visual reference point that supports both the understanding of complex relationships and communication skills.
Following the review, it becomes apparent that the results are difficult to understand (H4). The lack of context makes it hard for the person who wrote down the feedback, even more so for other team members, and particularly difficult for people who were unable to attend the review. This makes it more challenging, time-consuming, or ultimately impossible for the team to derive specific tasks together. As a result, knowledge is lost and implementation is delayed. To facilitate the flow of knowledge and information, a method is needed that supports the localization of comments and derived next steps on the component.
4.1.2. Derivation of requirements
The challenges described above show that important information about the development steps and their background is not sufficiently visible or comprehensible in the current review process. On this basis, several requirements for a visualization method can be derived that should specifically support the process. The following five requirements represent the most important aspects, without however providing a complete catalog.
The difficulty of establishing a common understanding of previous developments at the beginning of a review (H1) highlights the need to clearly present key differences. Therefore, visualization should make EC&Ds visible across different stages of development (R1). This gives all participants a quick overview and allows them to focus on relevant topics early in the review.
The observed tendency toward unstructured discussions, which are often conducted without reference to overarching contexts (H2), makes it clear that important interactions in the product are difficult to identify. To close this gap, visualization should make interactions between EC&Ds and components recognizable (R2). The goal is to make it easier to understand contexts and to be able to discuss decisions and their effects in a more informed manner.
Another problem is that feedback in the review is often documented without any spatial reference, making it difficult to understand later (H3). The visualization should therefore offer the possibility of locating feedback directly on the product (R3). This prevents misunderstandings and makes it easier for team members who did not participate in the review to understand the feedback.
After the review, it also becomes apparent that the results are often not sufficiently clear to derive concrete next steps (H4). Therefore, visualization should support the prospective planning of the next sprint (R4). It should not only record feedback but also help to derive actionable tasks from it.
Across all challenges, it becomes clear that there is a lack of a common visual reference point that provides orientation and at the same time reduces the amount of information. Therefore, visualization must create clarity and reduce superfluous information (R5). A well-structured visualization should help participants quickly reach a common understanding and focus on the relevant content.
Based on these derived requirements, the central working hypothesis of this study is formed: It is postulated that a visualization method fulfilling requirements R1 to R5 will effectively resolve the observed communication barriers (H1–H4) and outperform unstructured documentation methods regarding clarity and planning precision.
4.2. Design of the visualization method
The following section presents a product-related visualization method designed to help overcome the challenges identified in connection with reviews.
The visualization method developed is divided into three successive views, which use and create planning, process and realization data. All three visualizations are based on an exploded view of the product or module, that is to be developed. This form of visualization has proven to be particularly suitable for illustrating a large number of the requirements such as visual clarity and understanding of correlations.
The three views serve different purposes in connection with reviews and sprint planning. The first figure is a retrospective view of the EC&Ds made in the last sprint. The middle figure is used to quickly but precisely record information and feedback during the review with reference to the components. The last figure is aimed at prospective planning of the next steps. The visualizations are not only created once during the development process, but iteratively for each review or sprint change. Figure 2 shows the three figures in the context of the sprint-based agile working method. The exact structure and creation of the three figures are described in detail below.
General description of the visualization method and classification in the agile product development process with regard to the data collection framework (Reference Kull, Schlegel, Förster, Albers and BursacKull et al., 2025)
4.2.1. Retrospective view
The first exploded view is created in preparation for the review. It shows the EC&Ds made during the last sprint. In this explosion view, the components are colored in one of the colors described below. Components that have been adopted unchanged are colored blue. Components that have been changed as planned according to the last sprint planning are colored orange. Components that have been changed unplanned or deviating from the sprint planning are colored yellow. Finally, components that have been newly added are colored purple.
This coloring provides a clear representation of the EC&Ds between development stages and makes it easier to focus on relevant areas (R1). Since unplanned engineering deviations or added components are summarized and prepared in advance, this provides a guideline that allows attention to be directed to problematic aspects. In addition, the visualization during the meeting helps all participants to understand both the interactions between components and between EC&Ds (R2).
4.2.2. Interactive review visualization
The second visualization is developed during the review. An exploded view of the same product or module is prepared for this purpose, but without coloring the components. It is intended to store information during the review. Any problems or ideas that are discovered can be noted directly on this exploded view using sticky notes. Arrows can be used to mark the exact location of one or more components.
Problems to be resolved, such as collisions, can be marked on red sticky notes. Own ideas, for example from the backlog, are noted on pink sticky notes, and optional ECs or those with low priority on yellow sticky notes.
This approach makes it easier for the team to orient themselves. Even people who did not participate in the review can quickly grasp which aspects of which components have critical problems (R3). By using digital whiteboard tools such as Miro, the review can be carried out digitally and collaboratively. However, it is also possible to carry it out on a physical whiteboard.
Since notes are initially created according to the “brain dump” principle, there is no need for structured wording. The visual nature of the method significantly reduces the number of words needed to describe the problem and the affected region of the component in question. This helps to avoid miscommunication and allows information to be recorded in a time-efficient manner during the review (R3), (R5).
4.2.3. Prospective sprint-planning view
While the retrospective view serves to reflect on past developments and the interactive review visualization serves to collect knowledge, the prospective view aims to plan the next steps. This addresses a key challenge identified in the first descriptive study. The transfer of comments and ideas from reviews into comprehensible product-related tasks was either not carried out or was unstructured and without any link to the product context. The prospective view supports sprint planning in order to add structure to this process (R4).
The basis of the prospective view is the second visualization, developed previously in the review, with sticky notes that were filled with comments and ideas according to the brain dump principle. This illustration is reviewed after the review and converted into concrete action steps. To do this, a blank exploded view is used again, on which the action steps are assigned to the respective aspects of the affected components with sticky notes and arrows in their exact positions. The color of the sticky note can be used to prioritize the tasks.
In regard to the agile product development process, the prospective view is developed as part of sprint planning following the review. The visualization serves as a basis for communication within the team and enables subsequent traceability of what has been discussed (R3). The spatial allocation of tasks helps to identify connections and potential interactions between tasks (R2). In addition, working together on this visualization promotes a uniform understanding of the entire team regarding the development status and upcoming tasks (R5).
The prospective view is the final step in the visualization method. It closes the loop between review, insight, and planning and creates a basis for improved communication and planning within iterative development processes.
4.3. Application of the visualization method
The visualization method presented is now applied to two development processes to observe its applicability and usefulness.
4.3.1. Application of the visualization method to past GSD data
As part of this study, the visualization method was applied to three reviews from the previous GSD development project. Figure 3 provides an overview of this. For each review, a retrospective visualization of the EC&Ds was created. Based on these, the EC&Ds and development decisions of the respective sprint were presented to stakeholders once again in order to examine whether the visualizations contribute to a better understanding of the system. Furthermore, comments collected in bullet point form are transferred to the second figure. This allows us to examine whether the comments from a review can be noted in this form. Finally, a prospective planning visualization was also created for each case, and the planning at that time was re-examined on the basis of the visualization.
Application of the visualization method to previous GSD data
Figure 3 Long description
Panel A: A diagram showing sketches and CAD models. The sketches are represented by hand-drawn shapes in various colors, while the CAD models are depicted as three-dimensional geometric forms. Panel B: A diagram displaying exploded views. The components are shown disassembled and spread out, with arrows indicating their connections and relationships. Panel C: A diagram illustrating functional and cause and effect diagrams. Functional diagrams show the interactions between different components, while cause and effect diagrams depict the relationships between events and outcomes. Panel D: A diagram representing process models. The processes are shown as a series of steps connected by arrows, indicating the flow of activities. Panel E: A diagram showing variant trees or configuration models. These models illustrate the traceability of product families and change states, with branches representing different variants and configurations.
4.3.2. Application of the visualization method in a product development process
In addition to its application to past GSD data, the visualization method was applied to an ongoing development process. This process involves further developing the top-heat grill created in GSD. As shown in Figure 4, all three illustrations of the visualization method were created for review and sprint planning. In this case, the prospective view could be evaluated again to coordinate the next sprint’s planning steps.
Application of the visualization method in an ongoing development process
5. Discussion
The objective of the work was to develop a product-related visualization method that supports reviews and sprint planning and facilitates both retrospective communication of changes and prospective planning. The following section will assess the feasibility of implementing the visualization method in real-world applications and evaluate its potential benefits in such contexts. The evaluation is based on qualitative observations from two perspectives: retrospective application to existing development data and active application within an ongoing development process.
Regarding the first requirement (R1), making changes visible across different stages of development, the use of the retrospective view showed that highlighting changes in color enabled quick orientation. In addition to its application in the review environment, the retrospective view also proved advantageous in other areas when explaining changes to outsiders. Significant changes could be identified immediately, which made it easier to structure analysis. The ability to swiftly discern discrepancies between planned and actually implemented changes and to search specifically for their causes was particularly helpful. Consequently, R1 is met in its entirety.
The second requirement (R2), making interactions between changes and components visible, proved to be particularly beneficial in both retrospective analysis and in the ongoing development process. The application of the visualization method made it possible to identify affected components more quickly and to better assess the potential impact of planned changes without having to reconstruct these relationships solely from verbal descriptions. However, it should be noted that the development processes examined were relatively simple, as this was a student project. It is imperative to investigate whether adjustments would be required to apply the visualization method to more complex product architectures. Under the given conditions, R2 was clearly fulfilled.
The third requirement (R3), to locate feedback directly on the product and make it traceable later, had a strong effect in practice. When transferring previous, exclusively text-based notes into the visualization, it became clear that these could be shortened considerably and at the same time formulated more precisely. Spatial references could be displayed immediately, which meant that fewer explanatory additions were necessary. This reduced the risk of misunderstandings and made it easier to understand the original feedback retrospectively. R3 is thus fulfilled to a high degree.
The fourth requirement (R4), to use the method for prospective planning and to support the derivation of concrete next steps, was confirmed above all during the ongoing development process. The immediate visibility of the affected components made it possible to derive clearer action steps that logically resulted from the observed problems. However, it remained unclear to what extent the method could support the delegation of such tasks to several team members, as this issue was not examined in the present context. Overall, R4 is largely fulfilled, although the impact on delegating tasks remains unclear.
The fifth requirement (R5), to create clarity and reduce superfluous information, was reflected in both application scenarios. The compact visual presentation made it easier to focus on the essential aspects of the product and reduced the amount of additional information that needed to be recorded. Observations showed that the application of the visualization method made it easier to organize and interpret information, which in turn enabled faster engagement with the relevant topics. Under the given conditions, R5 is clearly fulfilled.
The present discussion has shown that the visualization method developed meets the formulated requirements very well in the environments examined. The product-oriented form of presentation promotes understanding of the development status and current obstacles as well as planned changes. The method thus serves as a tool between retrospective reflection and prospective planning.
It is particularly noteworthy that the method creates a shared view of the product, which helps to avoid misunderstandings. It is evident that the visualization method provides substantial added value for reflection, communication, knowledge acquisition, and planning within agile product development. In summary, the validation of requirements R1 through R5 provides qualitative evidence to support the study’s central hypothesis. The results confirm that meeting these specific visualization requirements directly correlates with improved transparency and structured planning in the observed agile environments, justifying further quantitative research.
6. Conclusion and outlook
In this work, a product-related visualization method was developed to improve efficiency of reviews and sprint planning. This supports both the communication of retrospective engineering changes and deviations in reviews and the prospective planning of tasks.
The challenges were derived from the practical experience of a development process, and the visualization method was applied in two contexts for evaluation in order to analyze its usefulness and applicability. On the one hand, it was applied retrospectively to existing data, and on the other hand, it was applied during an ongoing development process.
The results of the study suggest that the method improves information exchange, increases the traceability of decisions, and structures the planning of next steps.
In addition, it was found during the application of the visualization method that it could also be transferred to prototype testing or other forms of knowledge acquisition. In terms of documentation and communication capabilities, visualization could offer similar advantages as it does in reviews. However, it is necessary to examine the extent to which the visualization logic would need to be adapted.
In addition, studies in several student development projects and in companies are further empirically investigating the benefits in terms of applicability and the effect on engineering changes and deviations. The visualization method presented demonstrates that specific visual support in development processes not only facilitates communication but can also be an effective tool for knowledge retention, reference based engineering and decision-making.
Acknowledgement
The authors gratefully acknowledge the support of the research project “Development of an ontological model of the PGE and methodological support for the reduction of engineering change and planning deviations in sheet metal construction” with project number 530789856 by the funding of the German Research Foundation (DFG).
Open access
