This chapter will provide an overview of the project, addressing scope, time, cost, quality, communication, project plan, sprint scrums, and sprints.

The project scope is limited to developing a POC of the smart bottle. The technical focus will be on reading certain minerals from the water and enabling communication with the app. The prototype will be tested in a controlled environment and is not intended for full deployment in a real live operating environment.

In addition, to the technical prototype, the project will include a full-scale report on how the bottle should look and act. The report will include recommendations for future development, deployment plans, dataset improvement, integration opportunities, and potential risks.

Project Start: 6 of March 2026

Team Preparedness: The team members should have the required knowledge and skills in configuring ESP32, marketing, ethics, and all the chapters mentioned in the report. Preparatory training or upskilling may be necessary if he team lacks specific expertise.

Stakeholder Communication: Establishing effective communication channels with stakeholders, including the client and end-users, is a precondition. Clear communication protocols should be in place to gather feedback and requirements.

Risk Assessment and Migration Plan : The project needs to perform a risk assessment beforehand to pinpoint potential risks and create plans to manage them. This prepares the project to handle unexpected challenges effectively.

Test Envoironment: It is crucial to have a testing environment for thorough application testing before deploying it. This testing environment needs to closely resemble the final deployment environment.

This subchapter underlines the deadlines that must be met. Documenting key milestones and linking them to deadlines is crucial for clarity, accountability, and progress tracking. It ensures teams stay aligned, allows for early identification of potential risks, and enables timely adjustments. A well-structured timeline enhances efficiency and significantly increases the likelihood of project success.

2026-02-28: Choose top 3 projects

2026-03-11: Upload black box diagram and Structural Draft

2026-03-18: Upload the List of Components and Materials

2026-03-21: Define the Project Backlog, Global Sprint Plan, Initial Sprint Plan and Release Gantt Chart

2026-03-25: Upload System Schematics & Structural Drawings + cardboard scale model

2026-04-12: Upload Interim Report and Presentation

2026-04-16: Interim Presentation + feedback

2026-04-22: Upload 3D model video

2026-04-29: Upload final List of Materials (local providers, price, VAT, transportation)

2026-05-02: Upload refined Interim Report (after feedback)

2026-05-13: Upload packaging solution

2026-05-27: Upload Functional Tests results

2026-06-13: Upload Final Report, Presentation, Video, Paper, Poster and Manual

2026-06-18: Final Presentation + Individual Discussion + Assessment

2026-06-23: Update wiki, report and paper (corrections), Upload refined deliverables (source + PDF + code + drawings), Submit printed poster, brochure and leaflet

2026-06-25:Prototype demonstration,Submit prototype and user manual

The project budget was defined specifically for the development of a single smart water bottle prototype, with the 100 € allocation covering only the material and component costs required for one unit. The largest expenses were associated with electronic components, sensors, and structural materials. Key elements included the microcontroller, TDS sensor (for water quality), FSR406 pressure sensor (for water level), and LIS3DHTR accelerometer (for motion detection). Additional components such as MOSFETs and supporting circuitry were also required to ensure safe and reliable operation.

Mechanical elements included the bottle, UV-C protection materials, and mounting components. Smaller items such as wires, fuses, and prototyping boards were not included in the budget, as they were already available in the university laboratory.

The budget was carefully managed throughout the project lifecycle. Multiple Portuguese suppliers were evaluated to achieve a balance between cost, quality, and delivery time. Where possible, components were sourced from a single supplier to minimise shipping costs. A deliberate decision was made to avoid ordering from China, improving delivery reliability and lead times at the expense of slightly higher costs.

In some cases, sourcing from multiple suppliers resulted in increased shipping expenses. Although lower-cost alternatives were available, the team prioritised components that best satisfied the technical requirements and overall system design. The approach focused on maintaining performance while controlling costs where feasible.

The final prototype cost reached 108.19 €, exceeding the initial 100 € budget by 8.19 € (approximately 8 %). This variance was mainly due to shipping costs, VAT inclusion, and slight underestimations during the planning phase. Despite this, the deviation remained relatively small and acceptable for a prototype.

Overall, the budget was effectively controlled, with only a modest increase from the original 100 € estimate. All critical system requirements were successfully achieved. The project highlights the importance of appropriate component selection, supplier management, order consolidation, and leveraging available resources to optimise costs.

In addition to the material cost per prototype, the development of the system involved personnel costs associated with a team of six engineers. Each engineer worked an average of six hours per day over a four-month period, excluding weekends. This corresponds to approximately 88 working days per engineer, or 528 hours per person, resulting in a total of 3 168 working hours for the entire team.

Assuming an average hourly salary of 14 €, the total personnel cost for the development phase is estimated at 44 352 €. This value reflects the full design, development, integration, and testing process. While not included in the per-unit prototype cost, it represents a significant investment that would typically be distributed across units in a large-scale production scenario.

To ensure the smart water bottle system meets all functional, safety, and performance requirements, a set of quality metrics was defined. These metrics allow us to verify that each component and the complete system works as intended and safely.

All sensors are tested for accuracy and reliability. The TDS sensor must measure water quality within ± 10 % of reference values. The temperature sensor should read within ± 2 °C.

The pressure sensor (FSR406) is used to determine the water level in the bottle. It measures the force exerted by the water on the bottom of the bottle. The water height can then be calculated using the formula:

h = F / (A · ρ · g)

Where:

• h = water height (m)
• F = force measured by the sensor (N)
• A = area of the bottle base in contact with water (m²)
• ρ = density of water (~1000 kg/m³)
• g = gravitational acceleration (~9.81 m/s²)

This allows the system to detect empty, half-full, or full states accurately. The accelerometer (LIS3DHTR) is tested to ensure it correctly detects motion and orientation, allowing the system to respond appropriately to movement. Sensor outputs are compared against reference measurements, with calibration applied in software if necessary.

The system’s power consumption is monitored in all operating modes. Idle power should stay below 100 mW and normal sensing should remain below 1 W. Battery life is verified to provide at least six hours of normal use, with charging completed within four hours, while ensuring no overheating occurs.

The system is expected to operate reliably, with uptime of at least 95 %, no unexpected resets, and consistent sensor readings over time. The OLED display is tested for quick updates (less than one second) and clear readability in normal lighting conditions.

All electrical components are designed and tested for safe operation. A fuse protects the system from overcurrent, while MOSFETs control high-power components safely. Circuits are fully isolated to prevent short circuits. The bottle incorporates a circuit-killer switch in the base, which automatically disconnects power when the bottle is disassembled for cleaning. The geometrical design in the bottle cap ensures no UV light escapes when the bottle is closed.

During assembly of the prototype, careful safety measures will be taken to minimize exposure to UV-C light, including proper handling, protective gear, and avoiding powering the LED unnecessarily.

Quality is verified through functional testing, calibration, power measurements, long-term operation, and safety testing. Components are first tested individually, then as part of the complete system. Any metric that does not meet its threshold is documented, corrected, and retested until all standards are met.

A deliverable is considered acceptable when all defined thresholds are met, the system operates reliably, and no safety issues are present.

The stakeholder analysis is meant to assist the project group to understand who has interest and power over the project. It is a way to recognise who will be affected by the final product and to be able to categorize everyone involved in order to plan how the project group will interact with them throughout the project. Stakeholders will be split into four separate groups: Key Figure, Influencer, Interested and lastly, Spectator. All the stakeholders would be placed against 2 axes, representing their interests and influence. As this is an internal project, the number of stakeholders is limited.

Mendelow Matrix

Key Figures: Clients, Lecturers / Coordinator and the Project Group

Influencers (Low Interest, High Influence): ISEP BOARD

Interested (High Interest, Low Influence): Material Providers

Spectators (Low interest, Low influence): Logistic Parteners

Figure 2 … is a stakeholder Analaysis

Analysis of Stakholders __

Spectator: Logistics Partners: While not directly involved, they may eventually experience benefits from an improved inspection system. However, their role is passive, and they will not influence or interact with the project.

Interested: Project Group: The student developers have the most motivation to succeed and interest in creating a functional system but have limited influence over scope once defined by stakeholders. Future investors: They will invest money into a product so a close look on them must be keept

Influencer:
ISEP Board: though not actively participating in the project, defines academic frameworks and grading guidelines. Competiros: TRAQUA must keep an sharp eye on what the competitors develop and do while keeping their product fresh and at a decent price.

Key figures: Clients are central to the project's direction and success. They define the problems.

Lecturers: Advise the group and evaluate project quality. Offers ongoing feedback and determines part of the final grade.

TRAQUA has several ways of communication. Firstly, the team uses WhatsApp to communicate. This makes communication easy and provides a fast way to share ideas and receive feedback. Microsoft Teams channels are used to store documents and organize files depending on the team’s needs.

Meetings with teachers are organized every Thursday. The team is obliged to share an agenda by Tuesday evening at the latest so that teachers can prepare any necessary materials. These meetings are used to show the team’s progress, ask questions, and share ideas. After these meetings, the team gathers to hold retrospectives and discuss the upcoming sprint.

These sprint retrospectives and all sprint-related activities are documented and kept in Jira.

To maintain good contact with suppliers, it is important to keep each other informed. That’s why regular meetings are useful. Every one or two months, a meeting is planned. This allows both the supplier and TRAQUA to gather all their information and questions and discuss everything together, instead of sending multiple emails throughout the week or month. This saves everyone from dealing with many small tasks.

Customers will have the opportunity to subscribe to a free newsletter that will update them on the company’s goals and provide additional composting tips. The application will also include easy access to customer support, ensuring that all customers can reach the company easily.

To keep charities involved, the company will also organize meetings with them to discuss relevant topics. This helps maintain strong and high-quality partnerships.

This chapter handles the possible risks that may be met during the project and ways to tackle them. This is shown in the table below.

Table 1 …

Risk analaysis

Data leaks (12) The system will be processing sensitive business data, which could, in theory, be leaked to unauthorized parties. This security breach could affect all users of the application. Due to the reputational damage to the product, potential financial losses for the customers, and the legal liability this entails, this risk is classified as catastrophic. And, since the likelihood of malicious actors trying to exploit the system increases with the amount of users, this risk should be considered as probable.

Battery exploding (8) This risk refers to the physical hardware used to run or interact with the application particularly mobile or IoT devices experiencing battery failure or thermal runaway. Although rare in modern consumer hardware, the possibility cannot be entirely dismissed, especially if the application runs intensive background processes that cause sustained high CPU or GPU usage. The likelihood of this occurring is classified as remote, given the robustness of battery management systems in contemporary devices. However, the severity is catastrophic, as battery explosions can cause physical harm to users or damage to property, making this a high-priority risk despite its low probability.

Application downtime (4) Application downtime refers to periods during which the system becomes unavailable to users. This can occur due to infrastructure failures, deployment errors, resource exhaustion, or unexpected spikes in traffic. Given that the application is cloud-based and relies on several interconnected services, the probability of experiencing some form of downtime is frequent. However, its severity is classified as negligible, as modern deployment practices — such as rolling updates, health checks, and auto-recovery mechanisms ensure that any disruption is typically brief and affects only a limited number of users at any given time. Proper monitoring and alerting further mitigate the impact.

API downtime (4) API downtime refers to the unavailability of third-party or internal APIs that the application depends on to function. This includes payment processors, authentication services, AI model endpoints, or data providers. Such outages can degrade or fully disable core application features. The likelihood of API downtime is classified as remote, since reputable providers maintain high availability SLAs; however, the severity is marginal, as only a subset of users or features will typically be affected during any given outage. Implementing retry logic, fallback mechanisms, and graceful error handling reduces the impact significantly.

Battery residue in materials (2) This risk concerns the presence of hazardous chemical residues in the batteries of hardware components used in development or production environments. Battery residue such as lithium compounds or electrolyte leakage — can pose environmental and health hazards if not properly handled or disposed of. The likelihood of encountering this risk is improbable under normal operating conditions, and the severity is marginal, as exposure is limited to those directly handling physical hardware components. Following standard electronics disposal and safety protocols effectively mitigates this risk.

UV-C radiation (1) UV-C radiation refers to the potential exposure to ultraviolet light emitted by certain hardware components—such as UV-C sterilization modules that may be used in specialized deployment environments. This risk is improbable in the context of a typical software application, as UV-C sources are not standard components in consumer or enterprise hardware setups. The severity is classified as negligible, since even in environments where such components exist, safety enclosures and regulatory compliance requirements strictly limit human exposure. This risk is included for completeness but presents no meaningful threat to standard application development or deployment.

Short circuit (1) A short circuit risk refers to electrical faults in the hardware infrastructure supporting the application, including servers, networking equipment, and end-user devices. While short circuits can cause equipment damage or data loss, their occurrence is improbable given the use of modern, certified hardware with built-in circuit protection. The severity is negligible, as affected equipment is typically isolated automatically by circuit breakers or surge protectors, and redundant infrastructure ensures service continuity. Routine hardware maintenance and compliance with electrical safety standards are sufficient to keep this risk at an acceptable level

The procurement strategy was designed to ensure that all required components are available on time and that the project can progress without delays. The main focus was on selecting components that are reliable, compatible, and easy to obtain within the project timeframe.

Each component was reviewed before ordering to confirm that it meets the system requirements and can be integrated without issues. This reduced the risk of delays caused by incorrect or incompatible parts and helped keep the procurement process organized.

Most components were purchased, especially electronic parts such as sensors, the microcontroller, and the display. These components require precise manufacturing and are not practical to produce within the project.

Some mechanical aspects, such as the internal mounting and positioning of components inside the bottle, were designed and assembled by the team. This allowed flexibility during prototyping and made it easier to adjust the design when needed.

Suppliers were selected based on availability, delivery time, and reliability. Multiple suppliers were used to ensure that all required components could be sourced without delays. Preference was given to suppliers that provide clear specifications and consistent stock levels.

Procurement was carried out in phases. Components needed for early testing were ordered first, allowing development and prototyping to begin as soon as possible. Less critical components were ordered later, once the design was more finalized. This approach reduced the risk of ordering unnecessary or incompatible parts.

To reduce procurement risks, alternative components and backup suppliers were identified for critical parts. Datasheets were carefully reviewed before ordering to ensure compatibility. Procurement was started early to allow enough time to handle delays, missing parts, or specification issues.

This structured approach ensured a smooth procurement process and supported steady project progress.

The project was structured across eight sprints, preceded by a pre-work phase dedicated to topic selection and initial setup. Each sprint spans approximately one week, running from early March to late June 2026. The project management was handled using Jira, where all tasks were tracked and assigned across the team. The Gantt chart above provides a visual overview of the planned timeline, grouping activities by sprint and category. The pre-work phase covered foundational scrum activities such as stand-ups, retrospectives, and sprint demos, as well as general activities including assigning roles. Sprint 1 focused on initial research, documentation, and structural work. Subsequent sprints progressively addressed design, prototyping, coding, and testing. The final sprints are dedicated to the interim and final reports, functional tests, packaging solutions, and multimedia deliverables such as the video flyer and poster. This iterative approach allowed the team to review progress regularly through retrospectives and adapt the backlog accordingly, ensuring continuous alignment with project goals.

Figure 4 shows a timeline/backlog with EPICS in JIRA. Some timeline start and end dates are not visible, as those user stories have either not started yet or have already been completed. The team aligned the dates in JIRA with the deliverable deadlines.

Figure 5 and Figure 6 are the same concept but this is a Gantt chart done using Excel.

Document the project schedule, and the key project phases, using a Gantt Chart. Highlight the key project phases and milestones.

Gantt Chart and Key Project Phases

The project timeline spans from late February 2026 to late June 2026, structured across eight iterative sprints. The Gantt chart above illustrates the full schedule, with tasks grouped by sprint and color-coded by category to reflect their nature and status.The project was divided into five key phases:

1. Pre-work and Setup (Feb 28 – Mar 5): This phase covered project selection, initial scrum setup, role assignment, and backlog definition. The first milestone was submitting the top-3 project proposals by February 28.
2. Research and Documentation (Sprint 1–2, Mar 5–19): The team conducted research on water quality and filtration, produced the black box system diagram and structural drafts (milestone: March 11), and compiled the initial list of components and materials (milestone: March 18).
3. Design and Intermediate Deliverables (Sprint 3–4, Mar 19 – Apr 16): This phase focused on detailed system schematics, structural drawings, cardboard modelling (milestone: March 25), the Gantt chart and sprint plan publication (milestone: March 21), and culminated in the Interim Report and Presentation submission (milestone: April 12) and the Interim Presentation event (milestone: April 16).
4. Prototyping and Development (Sprint 5–6, Apr 16 – May 27): Following interim feedback, the team worked on the 3D model video (milestone: April 22), the final materials list (milestone: April 29), the refined interim report (milestone: May 2), backend and frontend coding, ESP32 integration, agent connectivity, and packaging solutions (milestone: May 13). Functional tests were concluded and uploaded by May 27.
5. Final Deliverables and Presentation (Sprint 7–8, Jun 1–25): The team produced the final report, paper, video, poster, and manual (milestone: June 13), delivered the final presentation and individual assessment (milestone: June 18), submitted all corrected and refined deliverables (milestone: June 23), and demonstrated the working prototype to the client (milestone: June 25).

Describe how your plan was mapped to multiple iterative sprints.

The project was managed using agile Sprint framewrok, with each week being a new sprint. Each sprint followed a consistent structure: a sprint planning session at the start, daily stand-ups throughout, and a retrospective and sprint demo at the end. This iterative approach allowed the team to regularly assess progress, incorporate feedback, and adjust priorities accordingly

The backlog was defined during the pre-work phase and browking into each sprint. Each sprint had a clear goal and aligned millestones.

Document how the sprint backlog was planned and managed for each of the sprints you have created in Planner.

The backlog was managed using Jira only. At the beginning of each sprint, the team sits down and plans the tasks based on priority and the upcoming milestones. Each taks then gets assigned to a member and tagged with its epic.

Tasks then get moved to either In progress, InReview or done. Incomplete tasks at the end of a sprint were reviewed and either carried over or re-prioritized in the following sprint.

Describe how prioritization was done.

Document how the estimation process was implemented, and any underlying challenges.

Period: March 5, 2026 – March 12, 2026

Sprint 7 was characterized by a heavy “Discovery” phase. The team focused on setting up the technical environment (TRAQ-43) and conducting deep-dive research into water quality and filtration systems. Because this was the inaugural sprint, a significant amount of time was spent refining the backlog and defining the complexity of the Interim Report. The team considered a total of 40 story points.

Key work streams Environmental Setup: Establishing the Scrum framework and project architecture. Technical Research: Analyzing water levels and filtration logic (TRAQ-11 through 14). Documentation: Initial drafting of the Background and Related Work sections for the interim report.

Period: Thursday, March 12th – Wednesday, March 19th, 2026

Sprint 8 followed a Thursday-to-Wednesday cycle. This schedule proved challenging this week due to a school trip on Friday, followed immediately by the weekend. This resulted in an unavoidable “stagnation period” at the very start of the sprint where no points could be burned down.

Period: March 19th, 2026 – March 26th, 2026

Narrative Summary Sprint 9 marked a transition from theoretical research to tangible outputs. The team successfully cleared the “documentation backlog” by finalizing heavy-weight chapters of the Interim Report. Simultaneously, the project moved into the design and physical modeling phase, with the creation of structural drawings and a physical cardboard model to validate the system's dimensions.

Technical Learning Point The team identified a discrepancy in how Story points are calculated when sub-tasks remain open. Moving forward, the Definition of Done (DoD) has been updated to ensure all granular tasks are closed before the parent Story is moved to “Done” to maintain burndown accuracy.

Period: March 26th, 2026 – April 1st, 2026

Sprint Goal: Finish up the Interim Report.

Sprint 10 was the final push toward a major project milestone. The team's efforts were almost entirely dedicated to consolidating research and development into the Interim Presentation and finalizing the core technical chapters of the report. This sprint confirmed the total unviability of the “Thursday-start” schedule, as the pressure to deliver high-point items was concentrated entirely into the final two days of the cycle.

Include the outcomes of all sprint reviews (what was the sprint backlog, completion status, planned capacity vs. achieved velocity).

Include the summary of all the sprint retrospectives, including any actions implemented as part of the team’s continuous improvement strategy. This section evaluates the effectiveness of each sprint by reflecting on what went well and what could be improved. It includes insights into challenges faced, team performance, and lessons learned to optimize future sprints.

The teams' first retrospective 11 underlined a few issue, the teams' different education backgrounds and spead, the teams' general workload, and the main idea being lost. To fix this the team decided to book a 1-hour meeting where everyone spoke for 5 min and said where they think the project should head. This helped us find common ground. Other conclusions regarding speed and workload: the team decided to meet more often to spread the workload fairly through the team.

The teams' second retrospective 12 underlines less issues then the first sprint. The team also wrote what they will be improving inside the retrospective.

Retrospective 13 mentions 3 main issues: sometimes it can be hard to define an equal amount of work for the team, some members being late, and lastly, some members still not being exactly familiar with the Scrum environment. The team decided to arrange a meeting where they would go over Scrum again and also to have longer sprint planning to properly define workload. General progress is still going good.

Retrospective 14 was the retrospective before the start of the vacation. The team now is getting ready for their interm report. No major issues faces the team will contact directly teachers regarding certain documents.

Provide here the conclusions of this chapter and make the bridge to the next chapter.