This chapter presents the project management approach used to organize and guide the development of Maris Habitats. It briefly explains how the team managed scope, time, cost, quality, stakeholders, communication, risk, procurement, and planning. The chapter also describes how Scrum and sprint evaluations were used to support progress and adapt to challenges during the project

Managing a project that intersects marine ecology, hardware engineering, and software development requires a framework that balances rigid constraints with creative flexibility. This chapter details the management strategy employed by the group, organized across key knowledge areas including scope, risk, and procurement.

Due to the unpredictable nature of environmental hardware testing, an Agile methodology (SCRUM based) was adopted. This iterative approach was essential for managing the project. By prioritizing continuous feedback loops and adaptive planning, the team was able to pivot in response to technical challenges without compromising the project's primary milestones or budgetary limits.

The scope of this project is the design and development of a functional prototype of a smart marine habitat intended to support seafloor biodiversity and enable environmental monitoring in underwater conditions. The project focuses on creating a concept that combines an artificial habitat structure with a basic sensor system, while taking into account sustainability, durability, and ecological compatibility [1].

From a product perspective, the project includes the development of a modular underwater habitat structure designed to provide shelter, attachment surfaces, and spatial complexity for marine organisms. In addition, the product includes an integrated monitoring concept based on selected sensors capable of collecting environmental data relevant to the surrounding habitat, such as temperature, pH, turbidity, or depth, depending on technical feasibility and component availability. The solution also includes a basic embedded electronics system for sensor integration, power management, and data handling, as well as a conceptual approach for transmitting or presenting the collected data. The overall product is intended to demonstrate how habitat restoration and environmental monitoring can be combined into a sustainable solution.

From a project perspective, the scope includes the research and analysis required to understand the environmental problem, existing artificial reef solutions, suitable structural materials, and underwater sensor technologies. It also includes the definition of requirements, concept development, design selection, structural modelling, component selection, and prototype integration. The project covers the testing and validation of the prototype under limited and controlled conditions, together with the assessment of market, sustainability, ethical, and project management aspects. The preparation of all academic deliverables, including the report, presentation, poster, flyer, and supporting documentation, is also part of the project scope.

The main outcome of the project is a functional prototype that demonstrates the technical feasibility and conceptual value of a smart artificial marine habitat. The prototype is intended to serve as a foundation for future development, testing, and scaling in real-world marine applications.

The Work Breakdown Structure (WBS) presented in the figures 1 and 2 illustrates how the Maris Habitats system is divided into its main components and subsystems [2]. The diagram provides an overview of the product architecture, showing how the habitat structure, sensor system, energy and communication, deployment, and maintenance elements are organized.

Each main component is further broken down into smaller elements, representing the key functionalities required for the system to operate. This visual representation helps clarify the scope of the project by identifying all relevant parts of the system and their relationships.

Figure 1 presents the WBS for the product and Figure 2 the WBS of the project.

To ensure effective time management and the timely completion of the project, tasks were scheduled to be completed during school hours and before weekends. This approach helped maintain steady progress and allowed time for review and adjustments when needed [3].

The team followed the milestone schedule defined by the project supervisors over a total project duration of 118 days, from 2026-02-28 to 2026-06-25. These milestones provided a structured framework to monitor progress and ensure alignment with the overall project timeline. Table 1 presents the defined milestones.

When estimating the total cost of the project, two main factors must be considered: employee salaries and the cost of materials and components.

The average salary for a junior engineer in Portugal is approximately 1 500 € per month, and the project duration is five months. With a team of six employees, the total salary cost is calculated as: 6 employees × 1 500 € × 5 months = 45 000 €.

The material costs are divided into two categories: components and sensors. The total cost of the electronics and components is 2215.66 €.

A detailed overview of the individual component and sensor costs is provided in Table 2.

In addition to the component costs, transportation and shipping costs must also be taken into account. These are presented in Table 3. Including shipping, the total cost of materials increases to 2558.85 €.

The project includes the cost of structural materials used for the habitat modules. Each block/module is composed of approximately 30 kg of concrete (C) and 70–90 g of basalt fiber (BF). These are shown in Table 4.

Based on current market prices, concrete costs 89 € per 1000 kg, while basalt fiber costs 34.16 € per 1.36 kg. This results in an estimated material cost of 2.67 € for concrete and 1.76 € for basalt fiber per block.

Therefore, the total material cost per block is approximately 4.43 €.

It should be noted that this estimate is based on small-scale purchasing prices. For larger production volumes, the cost per unit is expected to decrease due to bulk pricing and supplier agreements.

The total cost of the project, including labour, electronics, components, sensors, transportation and shipping, is estimated to be 47,558.85 €, excluding the structural material cost of the habitat blocks. The structural material cost is estimated at 4.43 € per block, depending on the number of blocks produced.

It is important to note that this cost estimate represents the final product configuration, and not the prototype.

Prototype list

When selecting electronic components for the prototype, efforts were made to replicate the final product as closely as possible within the constraints of a 100 € budget. In addition, components were sourced from as few suppliers as possible in order to minimize transportation and shipping costs.

The selected electronics used in the prototype are presented in Table 6.

The estimated total cost of the electronics is 102 €, including shipping, as summarized in Table 7.

For the remaining component selection, suppliers offering local pickup were prioritized in order to avoid additional transportation costs.

These materials are summarized in Table 8.

The different prototype cost scenarios are summarized in Table 9, showing how additional materials such as concrete and 3D printing filament affect the overall cost.

The impact of procurement strategy on shipping costs is shown in Table 10, where the difference between in-store pickup and online ordering is highlighted.

Although the estimated total cost exceeds the budget, some components and materials may already be available at the university, reducing the need for additional purchases. Furthermore, transportation costs may be avoided if other groups also are ordering from the same supplier and the total order exceeds the free shipping limit. Consequently, the actual cost is difficult to determine precisely but is expected to be lower than the estimated 136 €.

Quality in the project is ensured by defining measurable quality metrics for both the product and the documentation. These metrics help the team evaluate whether the system works as intended, meets the project requirements, and is clearly documented.

For the product, the main quality areas are sensor performance, waterproofing, structural stability, data logging, energy efficiency, maintainability, and environmental compatibility. For the documentation, quality is evaluated through clarity, completeness, structure, and consistency. The metrics are reviewed through prototype testing, design reviews, sprint meetings, and supervisor feedback [4] (see Table 11).

The quality metrics are checked continuously during the project. Technical metrics are reviewed through controlled prototype testing and design evaluation, while documentation quality is reviewed through team checks and supervisor feedback. If a metric does not meet the required threshold, corrective actions are added to the project backlog and followed up during sprint meetings.

People involved in a project can create uncertainty if responsibilities, communication routines and workload are not clearly defined. For this reason, people management is important in the Maris Habitats project. The project requires collaboration between team members from different academic backgrounds, including design, electronics, software, documentation, sustainability and project management.

The team does not have one permanent project manager. Instead, all team members share responsibility for project progress, decision-making and following the project scope. Tasks are distributed based on skills, availability, workload and interest in order to make the work more efficient and balanced.

The key factors considered when assigning tasks are:

Skills and expertise

Each team member has different knowledge and technical strengths. Tasks are therefore assigned according to individual skills, such as design, electronics, software, research, communication or documentation. This helps improve the quality of the project outcome.

Roles and responsibilities

Clear roles and responsibilities are important to avoid confusion, duplicated work and missed tasks. Each team member is responsible for completing assigned tasks and communicating progress to the rest of the group.

Availability and workload

The workload should be distributed fairly between team members. Since the project includes many different deliverables, such as the report, prototype, poster, video, manual and presentation, the team must make sure that no member is overloaded.

Interest and motivation

When possible, tasks are assigned according to each member’s interests. This increases motivation, engagement and productivity, while also helping the team produce better results.

Collaboration and team dynamics

Since Maris Habitats is a multidisciplinary project, collaboration is essential. Team members must share information, support each other and communicate regularly to make sure that the structure, smartblock, documentation and prototype development remain aligned. See 12 table.

The purpose of this structure is to ensure that all team members understand their responsibilities and contribute to the overall progress of the project. By combining different skills and distributing tasks clearly, the team can reduce uncertainty and improve collaboration throughout the project.

Stakeholder management refers to the identification, analysis, engagement and communication with individuals or organizations that can affect or be affected by the project. In the Maris Habitats project, stakeholder management is important because the solution is connected to marine restoration, environmental monitoring, academic requirements and future users of the system.

The project includes both internal and external stakeholders. Internal stakeholders are directly involved in the development process, while external stakeholders may influence the project or benefit from the final solution.

Key Stakeholders

Team members

The team members are responsible for developing the project concept, designing the structure, selecting components, building the prototype, testing the system and completing the required documentation. They are the main decision-makers during the development process and are responsible for keeping the project within scope.

EPS Coordinator

The EPS coordinator supports the team by organizing the academic framework and control meetings. The coordinator also helps ensure that the project follows EPS requirements and that deliverables are submitted according to the project timeline.

Project supervisors

The supervisors provide academic and technical guidance throughout the project. They review the team’s progress, give feedback on design and documentation, and help the team make informed decisions.

ISEP

ISEP is the hosting institution and provides the project environment, facilities, tools and academic structure. The institution also defines deadlines, evaluation criteria and general requirements for the EPS project.

Professors and advisors

Professors and advisors provide knowledge in different subject areas such as project management, ethics, sustainability, marketing, design and engineering. Their feedback helps improve the quality of the project.

Suppliers

Suppliers provide the components and materials needed for the prototype and final product concept. Delivery time, price, availability and component quality can affect the project schedule and technical feasibility.

Potential users and customers

Potential users include public institutions, coastal municipalities, research institutions, environmental NGOs, port authorities, aquaculture operators and marine infrastructure companies. These stakeholders may use Maris Habitats for marine restoration support, environmental monitoring, research or sustainability reporting.

Research institutions and NGOs

Research institutions and NGOs are important future stakeholders because they may use the collected environmental data for analysis, monitoring and marine conservation projects. They can also provide feedback on how the system should be developed further.

Public authorities

Public authorities may be involved in future deployment because underwater installations can require permits, environmental assessments and compliance with regulations. Their role is important for real-world implementation.

Marine life

Marine life is not a traditional stakeholder, but it is the primary beneficiary of the project. The design must therefore consider the needs of fish, algae, corals and other marine organisms by using safe materials, stable structures and habitat-friendly geometry. See 13 table

Engagement Strategy

The team uses weekly supervisor meetings, internal team meetings, Jira updates and wiki documentation to keep stakeholders informed. Feedback from supervisors and professors is used to improve the project and correct issues early. For external stakeholders, the main engagement strategy is based on clear documentation, realistic communication and future project presentations.

Risk Mitigation Related to Stakeholders

Stakeholder-related risks include unclear communication, delayed feedback, poor documentation, supplier delays and misunderstanding of project expectations. These risks are reduced through regular meetings, clear task distribution, updated documentation, early supplier research and continuous feedback loops.

Overall, stakeholder management helps ensure that the project remains aligned with academic expectations, technical requirements and future user needs. It also supports better decision-making and improves the feasibility of Maris Habitats as a marine restoration and monitoring solution [5].

Effective communication is important to ensure coordination, transparency and steady progress throughout the Maris Habitats project. Since the team consists of members from different academic backgrounds and nationalities, clear communication routines are necessary to avoid misunderstandings, distribute tasks effectively and keep all project work aligned [6].

Guidelines for Meetings

Meeting agenda

For the weekly supervisor meetings, a meeting agenda is prepared before the meeting. The agenda includes the main topics to be discussed, current progress, challenges, questions for the supervisors and tasks that need clarification. This helps the team use the meeting time efficiently and ensures that important issues are addressed.

Meeting minutes

Meeting minutes are written after the weekly meetings and uploaded to the wiki or shared with the team. The minutes summarize the topics discussed, feedback received, decisions made and new tasks or agreements. This makes it easier for all team members to follow up on responsibilities and keep track of project progress.

Pitch

One person is responsible for leading the pitch and making sure that the agenda is followed. This role can change between meetings depending on the topic being discussed and the team member responsible for that area.

Note taker

The note taker documents the main points discussed during the meeting. This includes supervisor feedback, decisions, action points and deadlines. The note taker is also responsible for helping update the meeting minutes.

Time keeper

The time keeper helps the team stay within the planned meeting time. During supervisor meetings, this responsibility is usually supported by the supervisors or professors, while in internal meetings the team members manage the time together.

Communications Matrix

Communication Tools and Means

Microsoft Teams is used as the main platform for receiving information, resources and announcements from professors and supervisors. It is also used to access shared project material.

Outlook is used for formal communication with professors, supervisors and external contacts. This includes meeting-related communication, questions and supplier contact when needed.

WhatsApp is used for fast internal communication between team members. It is mainly used for daily updates, quick questions, reminders and urgent issues that need to be solved quickly.

Jira is used as the main project management tool. The team uses Jira to organize tasks, update progress, manage sprint work and track responsibilities.

The wiki is used as the main documentation platform. Project information, report content, deliverables, meeting minutes and progress updates are uploaded there throughout the project.

Communication Approaches to Stakeholders

This communication structure helps the team maintain a clear workflow, follow deadlines and solve problems early. Regular meetings, shared documentation and continuous task updates support collaboration and ensure that all members remain informed about the development of Maris Habitats.

The project involves several potential risks related to both technical and organizational aspects. One of the main risks is technical failure, particularly in the integration of sensors, electronics, and structural components in a marine-like environment. To reduce this risk, the system is tested in controlled conditions and components are selected based on reliability and compatibility.

Another significant risk is project delays due to time constraints and task dependencies. This is managed through sprint planning, regular meetings, and the use of buffer time to accommodate unforeseen issues.

There is also a risk related to limited resources, including budget constraints and access to specialized equipment or testing environments. This is addressed by prioritizing essential features and selecting cost-effective solutions [7].

Team-related risks such as miscommunication or uneven workload distribution may affect progress. These risks are mitigated through regular Scrum meetings, clear task allocation, and continuous collaboration among team members (see Table 14).

To further support the risk assessment, a risk matrix based on probability and impact was used. The matrix classifies risks into three categories: low, medium, and high, depending on their likelihood of occurrence and potential impact on the project.

Based on this matrix, risks such as technical failure, power system failure, integration issues, and project delays are classified as high risk, as they combine medium to high probability with high impact. These risks require priority attention and mitigation (see Figure 3).

Risks such as limited resources, corrosion, extreme weather conditions, and data transmission failure fall into the medium-risk category. These are monitored and addressed through preventive design measures and planning.

Lower-risk factors, including team miscommunication and uneven workload distribution, are classified as low risk, as they have limited impact and can be managed through regular communication and task organization.

The use of this risk matrix provides a clear and structured way to prioritize risks and supports more effective decision-making throughout the project [8].

The procurement plan is presented in three tables. Table 15 provides an overview of the electrical components required for the habitat, while Table 16 presents the material composition and cost of the concrete blocks used in the habitat structure.

Each item includes both a primary supplier and a designated backup supplier, ensuring supply reliability and reducing the risk of delays due to stock shortages or delivery issues.

The project schedule was visualized using a Gantt chart to illustrate the timeline and key phases of the project.

As shown in Figure 4, the project timeline spans from March to June and includes overlapping phases such as research, prototype development, and documentation.

The global sprint plan provides an overview of the project timeline, including the duration of each sprint, start and end dates, and the number of available working days. Its main purpose is to ensure a realistic distribution of workload based on the team’s availability throughout the project period. See Table 17 for the global sprint plan.

By defining how long each sprint lasts and how many working days are available, the team can better plan tasks and avoid overloading specific periods. Variations in working days reflect differences in availability, such as holidays or other commitments, which allows for more accurate and achievable planning.

The project backlog contains all identified tasks required to complete the project. Tasks are continuously updated and prioritized based on project needs, deadlines, and dependencies. Completed tasks are marked as “Done”, while ongoing and future tasks are labeled accordingly. Table 18 lists the backlog.

Sprint 1 (Week 3: 19 Mar – 26 Mar)

Sprint Goal: Establish the project foundation by defining roles, conducting initial research, and setting up key project documentation (see Table 19).

The tasks in the sprint were divided into smaller activities, including research, documentation, design, and planning, in order to ensure efficient progress. Responsibilities were distributed among team members based on their respective roles, with a focus on areas such as research, documentation, and design. By the end of the sprint, key project elements such as clearly defined team roles, initial research, and planning documents had been completed, providing a solid foundation for the subsequent sprints.

The sprints officially started from 19 March to 26 March, as the previous weeks were mainly used to become familiar with Jira and project tools.

An overview of the outcomes from the initial sprints is presented in Table 20 and Table 21.

Sprint 3

The burndown chart for sprint 3 shows that additional tasks were identified and added at the beginning of the sprint, resulting in an increase in the total amount of work. This reflects a better understanding of the project requirements as the team moved from concept to design.

During the middle of the sprint, progress remained relatively stable, indicating that fewer tasks were completed in that period. Towards the end of the sprint, a significant decrease in remaining work can be observed, showing that most tasks were completed close to the deadline.

This pattern indicates that the team made substantial progress during sprint 3, particularly in the final phase, where key design elements and system components were defined. It also highlights the need for improved task distribution to ensure more consistent progress throughout the sprint (see Figure 5).

Sprint 4

The burndown chart for Sprint 4 shows a noticeable increase in workload at the beginning of the sprint, indicating that additional tasks were identified as the project scope became clearer. This reflects an ongoing refinement of requirements and system definition. Shown in Figure 6.

Throughout most of the sprint, progress was relatively slow, with only minor reductions in remaining work. A more significant decrease occurs towards the end, suggesting that many tasks were completed close to the deadline.

This pattern indicates that work was concentrated in the final phase of the sprint. Although the planned objectives were achieved, this approach suggests a need for better time management and a more even distribution of tasks across the sprint.

Sprint 5

The burndown chart for Sprint 5 shows no significant changes in the remaining workload throughout most of the sprint. This indicates that tasks were not actively tracked or completed within the sprint period. Week 5 is shown in Figure 7.

This sprint coincided with the Easter holiday, during which no substantial work was carried out. Additionally, the project management tool (Jira) was not updated during this period, resulting in a lack of visibility and progress tracking.

The sprint did not function as intended and cannot be considered effective from an Agile perspective. The absence of recorded progress highlights the importance of maintaining consistent engagement and updating project management tools, even during periods of reduced activity.

Sprint 6

The burndown chart for Sprint 6, shown in Figure 8, indicates limited progress during the initial phase of the sprint, suggesting that relatively little work was carried out at the beginning of the period.

Subsequently, an increase in the remaining workload can be observed. This is explained because the incomplete tasks from Sprint 5 were carried over into Sprint 6. As a result, the workload appears to increase rather than decrease at that stage.

Towards the end of the sprint, a noticeable reduction in remaining work is observed, indicating that several tasks were completed before the sprint was concluded.

This pattern reflects an improvement in task completion compared to the previous sprint. However, it also highlights the importance of maintaining consistent progress and timely updates in order to ensure accurate tracking and effective sprint execution.

Sprint 7

The burndown chart for Sprint 7, shown in Figure 9, indicates that the same issue persists, where tasks are not consistently updated or marked as completed during the sprint. As a result, the remaining work remains relatively constant for most of the period.

Towards the end of the sprint, a sharp decrease in remaining work can be observed, suggesting that tasks were completed or updated late. Consequently, the burndown does not follow a steady downward trend.

Sprint 8

The burndown chart for Sprint 8, shown in Figure 10 indicates an increase in scope at the beginning of the sprint, suggesting that tasks were added after the sprint had started. Furthermore, the chart shows that task completion is concentrated toward the end of the sprint, with limited progress observed during the earlier phases. As a result, the burndown does not exhibit a consistent downward trend, but rather a delayed reduction in remaining work.

Sprint 9

The burndown chart showed a more positive development during sprint 9 shown in shown in Figure 11. This was mainly because no new tasks were added throughout the week, and completed tasks were checked off regularly. However, the sprint contained relatively few tasks, and several of the tasks that were completed were finished early in the sprint. The remaining tasks were more extensive and required more time than expected, which resulted in them being moved to the next sprint.

Sprint 10 During Sprint 10, little progress was made until two days before the sprint ended, mainly due to vacation. As a result, most of the work was completed near the end of the sprint rather than being distributed evenly throughout the sprint period. See Figure 12 for the burndown chart.

Sprint 11 This sprint also showed poor time management, as several tasks were not checked off or updated when they were supposed to be. This made it harder to track progress accurately and reduced the effectiveness of the sprint planning. See Figure 13 for the burndown chart.

Positive Aspects During this week, the team worked well together and showed good coordination in roles and responsibilities. The wiki and Jira were kept relatively updated, and the team made solid progress in research and design. There were also strong ideas developed for the project’s features, structure, and overall concept, along with progress on the ethics work. Overall, the team showed improvement in both collaboration and organization.

Challenges During this week, the team faced several challenges. There was a lack of clear discussion about project expectations, which led to some uncertainty. Task division was not always effective, and deadlines were not used efficiently. The wiki and report structure were somewhat disorganized, with resources not properly organized or uploaded. Additionally, the team could have shown more initiative and been more critical of their work. Overall, better structure, clarity, and efficiency are needed moving forward.

Ideas for Improvement During this week, the team developed ideas to improve the project by focusing on one main “smartblock” with simpler supporting blocks. They also explored sustainable materials, clearer separation between prototype and final product, and ways to improve functionality, such as adding sensors and using 3D printing.

Actions for Next Week For the next week, the team should focus on finalizing the structure and deciding on the materials for the project. It is important to continue and complete the necessary research while also developing the product design. The team should create a few sketches and present them for feedback. Additionally, roles and tasks need to be clearly defined, and the wiki should be properly updated with sources and kept organized. Work on communication materials such as a flyer, key facts, and an elevator pitch should also be continued.

Positive Aspects During this week, the team made strong overall progress and showed improved organization. The wiki was well maintained, and Jira was used effectively to keep track of tasks. The product design became clearer, supported by good structural drawings and a successful cardboard model. There was also progress in marketing, and the team had good planning for the upcoming weeks. Overall, collaboration was strong, with everyone showing up on time and contributing to steady progress.

Challenges During this week, the team faced challenges due to missing components, which slowed progress and led to some waiting time. There were still uncertainties regarding materials, sensors, and electronics, and decisions about these were not finalized. Parts of the wiki were disorganized, and project management could have been more structured. Additionally, the team had not clearly defined a target customer and needed to improve consistency in updating and sharing progress.

Ideas for Improvement During this week, the team developed ideas to improve planning and analysis. This included visualizing the market analysis more clearly and creating a risk matrix to better understand potential challenges. The team also focused on preparing for the interim presentation in order to improve communication and confidence.

Actions for Next Week For the next week, the team should focus on deciding on materials and further developing the technical aspects, such as weight and water flow. Each member should take clear responsibility for specific parts of the project and break tasks into smaller subtasks if needed. The team should also create a plan for the upcoming period to stay organized and maintain steady progress.

Positive Aspects During this week, the team successfully delivered the scheduled presentations, and key project components were selected. This contributed to clarifying the technical direction of the project and ensured alignment among team members.

Challenges The communication presentation did not meet expectations. The content and delivery could have been better structured and more effectively communicated.

Ideas for Improvement No specific improvement ideas were identified during this period.

Actions for Next Week The team will focus on completing and submitting the interim report. Emphasis will be placed on ensuring that all required sections are finalized and meet the expected quality standards.

Positive Aspects The interim report was successfully completed and submitted, marking an important milestone in the project timeline.

Challenges The report was finalized later than planned, indicating inefficiencies in time management and task distribution. Ideally, the report should have been completed before the final deadline to allow time for review and refinement.

Ideas for Improvement No additional improvement ideas were identified during this week.

Actions for Next Week The team will begin preparing for the interim presentation, focusing on improving content clarity, structure, and delivery.

Positive Aspects The team made good progress in preparing for the interim presentation, demonstrating improved coordination and focus on communication aspects.

Challenges Some challenges were encountered during the week; however, they were not clearly identified or documented.

Ideas for Improvement Based on feedback from supervisors, the team identified the need to improve the visual identity of the project, particularly by incorporating marine elements such as fish into the flyer and branding materials.

Actions for Next Week The team will further develop the technical aspects of the smart system, with a particular focus on evaluating alternative battery options and improving the design of the smart module. In addition, work will continue on creating a 3D model video of the product to support visualization and presentation.

Positive Aspects The team identified a more suitable battery for the project, and the wiki was further improved. In addition, a meeting was held with Manuel, the project supervisor, to discuss the project and develop a more concrete plan moving forward.

Challenges The team was not able to create the 3D video as planned.

Ideas for Improvement No specific improvement ideas were identified during this sprint.

Actions for Next Week The team will finalize the selection of sensors, continue improving the wiki, and complete the 3D video.

Positive Aspects The team conducted a meeting with a professor, which provided valuable clarification on how to approach the project. The list of components and materials was finalized, and the SmartBlock of the product was completed.

Challenges The team has not yet completed the 3D video and continues to face challenges in effectively distributing tasks among members.

Ideas for Improvement

Improved task allocation and clearer responsibility distribution should be implemented to ensure steady progress. In addition, intermediate deadlines may help avoid delays in deliverables such as the 3D video.

Actions for Next Week The team will prioritize completing the 3D video and establish a more structured task distribution plan to improve workflow efficiency.

Positive Aspects The team started working on the scientific paper and completed the renders of the 3D model.

Challenges Due to vacation, limited progress was made during the sprint.

Ideas for Improvement Future sprint planning should take vacation and reduced availability into account to ensure that the workload is realistic and achievable.

Actions for Next Week Next week, the team should focus on completing the leaflet and the packaging solution.

Positive Aspects Despite the shortened working week, several key deliverables were completed, including the leaflet, packaging solution, 3D model, and user manual.

Challenges The sprint did not begin as originally planned, which reduced the available time for completing the sprint tasks.

Ideas for Improvement Future sprints should start according to the planned schedule to ensure that tasks are distributed more evenly throughout the sprint period. It may also be useful to account for vacations or reduced availability when planning sprint goals.

Actions for Next Week Next week, the focus will be on refining the 3D model, starting the prototype, and completing the scientific paper.

Positive Aspects During this week, the team made important progress by figuring out how to produce the 3D mould. The 3D video was also completed, and work began on both the testing phase and the prototype.

Challenges The main challenge was that not all prototype components had arrived or were available. This limited the team’s ability to continue with the full prototype assembly and testing as planned.

Ideas for Improvement No specific improvement ideas were identified during this sprint.

Actions for Next Week Next week, the team will focus on completing the scientific paper, starting the concrete part of the prototype, and carrying out all planned tests.

Positive Aspects
During this week, the team made good progress. The smart box was successfully made to work, which was an important step for the prototype. The scientific paper is also close to being finished. In addition, both the poster and the user manual were completed.

Challenges
The main challenge this week was that the 3D print drawing needs to be changed. This means that some adjustments must be made before the 3D printed part can be produced or used in the final prototype.

Ideas for Improvement
No specific improvement ideas were identified during this sprint.

Actions for Next Week
Next week, the team will focus on completing the prototype and making sure all parts are ready and working as planned.

The project has been managed using an iterative and structured approach, allowing the team to balance technical challenges with continuous development. Through defined scope, milestone planning, and Agile methods, the team has made steady progress in both design and implementation. While some challenges remain, particularly related to decision-making and organization, the project is moving forward with a clearer direction and improved collaboration.