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

The project scope (Figure 1) 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-life operating environment. In addition to the technical prototype, the project will include a full-scale report on how the bottle should look and function. The report will include recommendations for future development, deployment plans, dataset improvement, integration opportunities, and potential risks.

Project Start: 6th 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 the 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 Mitigation 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 Environment: 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 specific deadlines is crucial for clarity, accountability, and progress tracking. It ensures that teams stay aligned, allows for the early identification of potential risks, and enables timely adjustments. A well-structured timeline enhances efficiency and significantly increases the likelihood of project success.

Project Duration: 2026-02-23 → 2026-06-25 (123 days / ~17.5 weeks)

The following Table 1 shows all materials to be delivered and their respective delivery dates.

• Low — Well-defined task, short turnaround, low dependency on external factors.
• Medium — Moderate complexity or dependency on prior deliverables; recoverable if delayed.
• High — Blocks downstream work, depends on external factors (suppliers, hardware, feedback), or has cascading consequences if missed.

• List of Components (2026-03-18) — drives all sourcing and budgeting downstream.
• System Schematics + scale model (2026-03-25) — physical deliverable, hardware/material dependency.
• Final Materials List (2026-04-29) — depends on supplier responses, pricing, VAT, shipping lead times.
• Functional Tests (2026-05-27) — prototype must be working; bugs/hardware failures can cascade.
• Final deliverables bundle (2026-06-13) — largest single upload (report, presentation, video, paper, poster, manual); coordination-heavy.
• Prototype demonstration (2026-06-25) — final, non-recoverable; live hardware failure = project failure.

  Costs

The project budget covers the material and component costs for a single smart water bottle. The largest expenses are associated with the custom-manufactured bottle structure and the integrated electronics. Key electronic elements include 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 are required to ensure safe and reliable operation.The mechanical structure consists of a custom aluminium inner shell, an injection-moulded plastic outer shell with an insulating air gap, the UV-C safety baffle, the activated carbon filter housed inside the cap, threading rings, and the magnets used by the reed-switch kill mechanism. Smaller items such as wires, fuses, and prototyping boards are not included in the budget, as they are 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 minimize 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 prioritized components that best satisfied the technical requirements and overall system design. The approach focused on maintaining performance while controlling costs where feasible.

The total estimated material cost per unit is 155,25 €, exceeding the initial 100 € target by 55,25 € (approximately 50 %). This variance is mainly due to shipping costs, VAT inclusion, and slight underestimations during the planning phase. The deviation remains acceptable at this development stage. Costs will drop significantly once the product moves into mass production, as electronic components are sourced in bulk, custom mechanical parts benefit from amortized tooling, and shipping is consolidated. A reduction of at least 70 € per unit can be expected.

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 optimize costs.

Table 2 compares and discusses the different components.

Table 3 shows all the electronical components.

Table 4 visualises the costs per unit.

To ensure the smart water bottle meets all functional, safety, and performance requirements, a set of measurable quality metrics has been defined. These metrics apply to both the prototype and the production design and will be used during testing and validation. Where the prototype and production specifications differ (notably in materials and wall construction), both thresholds are listed.

The table above defines the intended quality requirements and planned validation criteria. Once assembly is complete, all metrics will be reviewed and validated by the project team through practical testing, calibration, inspection, measurement, and functional verification. For the prototype, dimensional and material thresholds reference the prototype's plastic-bottle-with-aluminum-foil construction. For the production design, the same metrics apply to the custom aluminum inner shell with plastic outer shell and air gap, and additional checks are added for UV-C reflectivity, light containment, and magnet–reed switch alignment. The team will record measurement results, compare them with defined thresholds, and identify any deviations. Any requirement that does not meet its target value will be addressed through design improvements, software calibration, or component adjustment before final approval.

The smart water bottle will be considered acceptable when the project team has verified that all defined quality thresholds are achieved, no functional or safety issues remain, and the magnet–reed switch alignment functions reliably in any assembled orientation.

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.

Based on the Mendelow Matrix 2 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 (High Interest, High Influence): Clients, Lecturers / Coordinator, Project Group
• Influencers (Low Interest, High Influence): ISEP Board, Competitors
• Interested (High Interest, Low Influence): Material Providers, Future Investors
• Spectators (Low Interest, Low Influence): Logistic Partners

Analysis of Stakeholders

Spectators — 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:

• Material Providers: Supply components and materials; their pricing, availability, and lead times directly affect the project budget and timeline.
• Future Investors: Will potentially invest money into the product, so a close eye must be kept on their expectations.

Influencers:

• ISEP Board: Though not actively participating, defines academic frameworks and grading guidelines.
• Competitors: TRAQUA must keep a sharp eye on what competitors develop while keeping their product fresh and at a decent price.

Key Figures:

• Clients: Central to the project's direction and success — they define the problem and validate the solution.
• Lecturers / Coordinator: Advise the group, evaluate project quality, offer ongoing feedback, and determine part of the final grade.
• Project Group: The student developers have the most motivation to succeed and interest in creating a functional system.

Communication Strategy

Each stakeholder group requires a different communication approach based on their position in the Mendelow Matrix. The Table 5 below summarizes how the project group communicates with each party and what is expected in return.

• Single point of contact: each external stakeholder is handled by one designated team member to avoid mixed messages.
• Documentation: all formal communication (client meetings, lecturer feedback, supplier quotes) is logged in the project wiki.
• Escalation: blockers are raised in the next standup; client/lecturer issues are escalated within 24 h.
• Feedback loop: after each milestone, feedback received is reviewed in the following sprint planning.

TRAQUA uses a structured set of communication channels, each chosen for a specific purpose: fast internal coordination, formal documentation, stakeholder alignment, and customer engagement.

Internal Team Communication

• WhatsApp — primary channel for day-to-day coordination, quick questions, and informal idea sharing. Fast and low-friction, ideal for immediate feedback.
• Microsoft Teams — used to store documents, organize files, and hold formal online meetings when in-person is not possible. Channels are structured by workstream (e.g., Hardware, Software, Documentation, Marketing).
• Jira — sprint backlog, task assignment, sprint retrospectives, and all sprint-related activities are documented and tracked here. Provides traceability from user story to delivered feature.
• Git (repository) — source code, schematics, and technical drawings are version-controlled. Commit messages reference Jira tickets for traceability.
• Project Wiki — central knowledge base for the report, meeting minutes, decisions, and deliverables.

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 each teacher meeting, the team gathers to hold a retrospective and discuss the upcoming sprint (Table 6). Outcomes are logged in Jira and the wiki.

Clients define the problem and validate the solution, so regular structured contact is essential.

• Bi-weekly progress meetings — demo current state, gather feedback, confirm direction.
• Milestone demos — aligned with major deliverables (interim presentation, functional tests, final prototype).
• Email — for formal questions, requirement clarifications, and document sharing.
• Meeting minutes shared within 24h of each meeting to confirm understanding.

To maintain good contact with suppliers, regular meetings are planned every one to two months. This allows both the supplier and TRAQUA to gather all their information and questions and discuss everything together, instead of sending scattered emails throughout the week or month. This batching saves everyone from dealing with many small tasks.

• Primary channel: email for quotes, orders, and specifications.
• Backup channel: phone for urgent availability or lead-time issues.
• Single point of contact: one team member owns each supplier relationship to avoid mixed messages.
• Documentation: all quotes, confirmations, and delivery dates are archived in the Teams supplier folder.

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.

• Newsletter — monthly, opt-in, covering company updates and composting tips.
• In-app support — chat / contact form for direct questions.
• Social media — for announcements, community engagement, and marketing.
• Response SLA — customer support queries answered within 48h.

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

• Frequency: quarterly alignment meetings.
• Purpose: discuss joint initiatives, impact reporting, and upcoming campaigns.
• Channel: in-person or video call, minutes shared afterward.

The Table 7 below summarizes all the platforms that are used for the communication.

Communication Principles

• Right channel for the right message: urgent = WhatsApp; formal = email; technical = Jira/Git; knowledge = wiki.
• Asynchronous by default: written communication preferred to respect everyone's schedule; meetings reserved for decisions and alignment.
• Document everything: every meeting produces minutes; every decision is logged.
• Acknowledge receipt: messages requiring action are acknowledged within 24h, even if the full answer comes later.
• No silent blockers: any blocker is raised in the next standup or immediately via WhatsApp if critical.

Communication Risks & Mitigation

The Table 8 below shows the communication risks and mitigations.

This chapter identifies the risks that may arise during the TRAQUA project and defines how they will be prevented, monitored, and managed if they occur. Each risk is assessed on two dimensions: likelihood (how probable it is) and severity (how damaging the impact would be). The product of these two gives a risk score, which determines the priority for mitigation.

Risks are categorized by type to make it easier to assign ownership and response strategy:

• Project risks — affect schedule, scope, budget, or team capacity
• Technical risks — affect hardware, firmware, software, or integration
• Operational risks — affect day-to-day execution and infrastructure
• Safety & environmental risks — affect user safety, health, or the environment
• Security & data risks — affect confidentiality, integrity, and privacy

Risk score = Likelihood × Severity. Scores are interpreted as:

• 1–4 Low — accept and monitor
• 5–9 Medium — actively mitigate
• 10–15 High — mitigate before development milestones
• 16–25 Critical — must be addressed before the project advances

The Table 10 below lists all identified risks, their assessment, the prevention strategy (applied before the risk occurs), and the response plan (applied if it does occur). Each risk has an assigned owner responsible for monitoring it throughout the project.

The risk matrix below 3 plots each risk by likelihood (y-axis) and severity (x-axis). Risks in the top-right corner are the highest priority.

Identifying risks once is not enough — they must be tracked throughout the project. The following monitoring process will be applied:

• Weekly risk check during sprint reviews: the team reviews the register and flags any change in likelihood or impact.
• Milestone reassessment: before each major milestone (design review, prototype, interim report, final delivery), the full register is re-evaluated.
• New risk intake: any team member can propose a new risk at any time; the Project Manager assesses it and adds it to the register.
• Closed risks: once a risk is no longer relevant (e.g., a phase is completed), it is marked closed but kept in the register for traceability.

The system processes sensitive data — water-quality measurements tied to user accounts and potentially location information. Unauthorized access could affect all users, cause reputational damage, trigger legal liability under GDPR, and erode trust in the product. Likelihood is high because malicious actors routinely target IoT endpoints and mobile APIs, and attack surface grows with user count. Prevention focuses on encryption in transit and at rest, strict access control on BLE pairing, and input validation. If a breach occurs, the response is to revoke affected credentials immediately, notify affected users within the GDPR 72-hour window, patch the vulnerability, and conduct a post-mortem.

The TRAQUA device uses a rechargeable Li-ion battery. While rare in modern hardware, thermal runaway can cause physical harm or property damage — making severity catastrophic despite low likelihood. Prevention relies on certified cells with an integrated Battery Management System (BMS), thermal testing during prototyping, and sealed battery compartments. Response: immediate disconnection, and if shipped units are affected, a recall procedure in coordination with the supervisor.

The project combines electronics, firmware (ESP32), mobile app development, and sensor calibration — a broad stack that no single team member fully masters at the start. Prevention is done through a skills gap analysis at kickoff, allocated training time in the first sprints, and proactive use of the supervisor and external mentors. If a specific blocker arises during development, the response is pair programming, requesting expert help, or simplifying scope on the affected feature rather than letting it block the critical path.

As the project progresses, stakeholders or team members may propose new features that seem small individually but collectively derail the schedule. Prevention is a clearly defined backlog with supervisor-approved scope, and a change-control rule: any new requirement is added to the backlog, not to the current sprint. Response: if a new request is genuinely essential, an existing item is removed to make room, keeping total scope constant.

If a team member drops out mid-project, remaining members absorb their workload, which can cascade into further delays. Prevention relies on documentation (so no knowledge is locked in one person's head), cross-training on critical tasks, and early warning signs picked up in weekly retrospectives. Response: immediate task reassignment, scope revision if needed, and escalation to the supervisor.

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 procurement is shown in Table 11.

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. Project management was handled in Jira, where all tasks were tracked and assigned across the team. The Gantt chart provides a visual overview of the planned timeline, grouping activities by sprint and category.

The pre-work phase covered foundational Scrum activities — stand-ups, retrospectives, and sprint demos — as well as general activities including role assignment. 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 the timeline and backlog with epics in Jira. Some timeline start and end dates are not visible, as the corresponding user stories have either not started yet or have already been completed. Dates in Jira were aligned with the deliverable deadlines defined in the Time chapter.

Figures 5 and 6 present the same schedule as a Gantt chart produced in Excel, offering an alternative view to the Jira timeline.

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

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

The project was managed using an agile Scrum framework, with each week constituting a new sprint. Each sprint followed a consistent structure: a 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 teacher and peer feedback, and adjust priorities accordingly.

The product backlog was defined during the pre-work phase and broken down into sprint backlogs at the start of each sprint. Each sprint had a clear goal aligned with the upcoming milestone deadlines.

The backlog was managed exclusively in Jira. At the beginning of each sprint, the team held a planning session to select tasks based on priority and the upcoming milestones. Each task was assigned to a team member and tagged with its parent epic (e.g., Research, Design, Documents, Code, Prototype, Tests, Interim Report).

During the sprint, tasks moved through four states: To Do, In Progress, In Review, and Done. Tasks not completed by the end of a sprint were reviewed in the retrospective and either carried over to the following sprint or re-prioritized in the backlog.

Prioritization was driven primarily by milestone deadlines defined in the Time chapter. Tasks blocking an upcoming deliverable (e.g., the Interim Report on April 12) were assigned the highest priority, regardless of their epic. Within a single sprint, the team applied a simple MoSCoW-style logic:

• Must have: tasks on the critical path to the next milestone.
• Should have: tasks improving deliverable quality but not blocking submission.
• Could have: nice-to-have improvements deferred if capacity ran short.
• Won't have (this sprint): items pushed to a later sprint or the backlog.

External dependencies (component delivery times, supplier responses, lecturer feedback) were also considered, with dependent tasks scheduled only after their inputs were confirmed available.

Tasks were estimated in story points during sprint planning, with the team converging on a value through brief discussion rather than formal planning poker. The total points committed per sprint ranged from roughly 30 to 50, depending on team availability and the complexity of upcoming deliverables.

Two main challenges emerged with estimation. First, the team's mixed academic backgrounds made it difficult to estimate cross-disciplinary tasks consistently — a task that seemed small to one member could be substantial for another. This was addressed by having the assigned member propose the initial estimate and the rest of the team challenge it only when there was strong reason to.

Second, in early sprints the team noticed that story points were marked as burned down before all sub-tasks of a parent story were closed, which distorted burndown charts. Following Sprint 3, the Definition of Done was updated to require all sub-tasks to be closed before the parent story could be moved to Done, restoring burndown accuracy in subsequent sprints.

The project was managed using an agile Scrum framework, with each week constituting a new sprint. Each sprint followed a consistent structure: a 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 product backlog was defined during the pre-work phase and broken down into sprint backlogs at the start of each sprint. Each sprint had a clear goal aligned with the upcoming milestone deadlines.

The backlog was managed exclusively in Jira. At the beginning of each sprint, the team held a planning session to select tasks based on priority and the upcoming milestones. Each task was assigned to a team member and tagged with its parent epic (e.g., Research, Design, Documents, Code, Prototype, Tests, Interim Report). During the sprint, tasks moved through four states: To Do, In Progress, In Review, and Done. Tasks not completed by the end of a sprint were reviewed in the retrospective and either carried over to the following sprint or re-prioritized in the backlog.

Prioritization and estimation are described in detail in the Project Plan section above.

Period: March 5, 2026 – March 12, 2026

Sprint 1 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. The team assigned a total of 43 Story points. Its the first week of discovery, so the main goal here was to discuss and gather as much information as possible about the possible topic and come up with the top 3 topic we would like to work on.

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 2 8 followed a Thursday-to-Wednesday cycle. This schedule proved challenging due to a school trip on Friday followed immediately by the weekend, which created an unavoidable “stagnation period” at the very start of the sprint where no points could be burned down. The story point total rose to 50 this sprint. This was because we had now chosen our topic and needed to research how and what exactly we wanted to apply, and how we wanted to execute it. Toward the end of the sprint the chart rises again. This was caused by a misunderstanding about how to close a story when not all of its sub-stories were finished.

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

Narrative Summary Sprint 3 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.

Story points went up to 58.5. The team started to incorporate daily meetings each meeting gets 0.5 story points. Also we were able to increase the workload because we had less classes. Our objective is to work more in the beginning and less at the end. Start with full power and then be more relaxed at the end. This sprint also had a lot of story points, as there were a lot of deliverables to be handed in.

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

Sprint Goal: Finish up the Interim Report.

Sprint 4 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.

Story point stats consistent with 53.5. Nothing major to add here. One thing to point out is that each sprint task gets finished up “later” because we start sprints on Thursday, meaning we have a straight-away weekend on our hands, followed by 3 working days.

Period: April 1st, 2026 – April 13th, 2026 Sprint Goal: Hand in the Interim Report. Sprint 5 11 was originally scheduled to end earlier, but the team extended it by two days for two reasons: a vacation period fell near the original end date, and the new end date was aligned with the scheduled meeting with the teachers, giving the team additional time to prepare for the Interim Report presentation. The sprint started with a commitment of 32 story points, which grew to 33.5 after TRAQ-164 (“Table of power budget”, 1.5 pts) was added to scope on the first day. The team closed out 21.5 points across 7 work items, including the report hand-in itself (TRAQ-155), the Interim Report (TRAQ-20, 10 pts), Schematics Version 3, the Website, the Application Prototype, and Retrospective 5. TRAQ-88 (“Chapter Project Management”, 12 pts) remained in progress and carried over to Sprint 6. The burndown tracked below the ideal guideline through most of the sprint, with the steepest drop between April 8–10 as the interim report deliverables were finalized.

Period: April 16th, 2026 – April 28th, 2026

Sprint Goal: Address feedback from the Interim Report and prepare deliverables for the final stretch.

Sprint 12 displayed the most extreme “late-crunch” pattern of the project so far. The remaining work stayed flat at the initial commitment of 40 story points until April 20th, with the entire burndown collapsing into a 2-day window between April 22nd and April 24th. The team closed 24.5 points across 9 work items, including the 3D model video (TRAQ-21, 8 pts), the report fixes following interim feedback (TRAQ-168, 8 pts), the leaflet, the poster, the smart system schematics review, the video addition, the lab parts check, three daily meetings, and Retrospective 6. TRAQ-88 (“Chapter Project Management”, 12 pts) remained in progress as expected — this item is intentionally kept open across sprints since new content is added to it on every cycle, and it will only be closed at the end of the project. The flat-then-cliff burndown shape reflects the team prioritizing deep work on the larger report and design items before logging completions in a single batch near the end of the sprint, rather than a true delivery delay.

The burndown opened at roughly 40 story points and stayed flat until April 20. Almost all progress was logged in a single batch around April 23, dropping the remaining work to about 15 points — meaning the team closed roughly 25 points but finished above the ideal guideline, with the rest (chiefly TRAQ-88) carried into the next sprint.

Period: April 23rd, 2026 – April 30th, 2026

Sprint Goal: Continue progress on project deliverables following the interim milestone.

The Sprint that is shown in figure 13 was the shortest sprint so far at one week, a tighter cadence following the interim report milestone. The sprint started with a commitment of approximately 23 story points. The burndown once again exhibited the team's characteristic “late-crunch” pattern: remaining work stayed flat from April 23rd through April 27th, dropped by a small amount on April 27th, then plateaued again before the bulk of completions were logged on the final day, April 30th. By the end of the sprint window shown, roughly 9 points had been burned down, leaving approximately 14 points still in progress at the time of capture. As in previous sprints, TRAQ-88 (“Chapter Project Management”) is expected to remain open by design, since content continues to be added to it across every sprint and will only close at the end of the project.

With an increase in classes, the team's total workload dropped to 23.5. This is also because the team focused on smaller tasks like Paper etc.

Sprint 8 in figure 14 covered the period from April 30th to May 14th, 2026, with an initial workload of approximately 61 story points. The burndown chart showed a typical late-crunch pattern: after a small reduction at the start of the sprint, progress stayed mostly flat until May 12th, when most tasks were completed. By the end of the sprint, the remaining workload had decreased to around 23 story points, showing significant progress despite work being completed mainly at the end of the sprint.

Major deadlines this week, so the workload increased to 60. Meet Sprint, a bug came up hence, the chart is going back up.

Sprint 9 in figure 15 covered the period from May 14th to May 21st, 2026, with an initial workload of approximately 55 story points. The burndown chart showed very limited progress during most of the sprint, with only small reductions in remaining work occurring near the end of the sprint period. By the end of the sprint, the workload had decreased to around 43 story points, indicating that only a small portion of tasks was completed during this sprint. The burndown remained far above the ideal progression line throughout the sprint, suggesting that several tasks were still ongoing at the time of capture.

Back to the regular ~50 sprint points. The task that never gets finished is Project Management, as each week we need to add more to it. The teachers also asked us to add more to the app and paper, which is why there is such a big gap in the sprint backlog

Sprint 10 in Figure 16 covered the period from May 21st to May 28th, 2026, with an initial workload of approximately 45 story points. Unlike previous sprints, progress was more evenly distributed throughout the week, with several reductions in remaining work occurring at different points rather than only at the end of the sprint. The workload gradually decreased from 45 to approximately 3 story points by the end of the sprint, indicating that almost all planned tasks were completed. The final sharp drop suggests that the last remaining deliverables were closed just before the sprint ended, leaving only a minimal amount of work still in progress.

Sprint 11 in Figure 17 covered the period from May 28th to June 4th, 2026, with an initial workload of approximately 50 story points. The burndown chart showed little progress during the first half of the sprint, followed by several significant reductions in remaining work between June 2nd and June 4th. By the end of the sprint, the workload had decreased to approximately 8 story points, indicating that most of the remaining tasks were completed. As in several previous sprints, a large portion of the work was finalized near the end of the sprint, resulting in a burndown pattern that remained above the ideal progression line until the final days.

Sprint 12 in Figure 18 covered the period from June 4th to June 11th, 2026, with an initial workload of approximately 31 story points. The burndown chart showed steady progress throughout the sprint, with several small reductions in remaining work occurring at regular intervals rather than being concentrated on the final day. By the end of the sprint, the remaining workload had decreased to approximately 14 story points. Although the team did not fully reach the ideal burndown line, the sprint demonstrated a more consistent completion of tasks compared to earlier sprints, reflecting a gradual closing of the remaining project activities.

A major drop in time as the team project is coming up to an end. Small tasks are remaining.

This subchapter documents the outcome of sprint 1.

The following Table 12 shows the outcome of sprint 1.

Sprint 1 Summary:

Main Achievements:

• Set up the Scrum environment and established the project foundation.
• Completed initial research on water filters, water quality, and water level analysis.
• Produced the Structural Draft and BlackBox Diagram, and drafted the Background/Related Work chapter.

Progress Check: 100% of the planned work for this sprint is finished.

Effort Breakdown:

• Tasks Planned: 11
• Tasks Finished: 11

This subchapter documents the outcome of sprint 2.

The following Table 13 shows the outcome of sprint 2.

Sprint 2 Summary:

Main Achievements:

• Researched UV-C protection solutions and produced the materials list and specification table.
• Updated the report based on feedback and developed multiple report chapters (Marketing Strategy, Eco-efficiency, Ethical Concerns, Project Development).
• Completed graphic design work and conducted Retrospective 2.

Progress Check: 100% of the planned work for this

This subchapter documents the outcome of sprint 3.

The following Table 14 shows the outcome of sprint 3.

Sprint 3 Summary:

Main Achievements:

• Built the Cardboard Model and developed the practical solution for the 3D system.
• Conducted companies research, updated background materials research, and produced the Flyer and Structural Drawings.
• Added the QR code to the Wiki, advanced multiple report chapters, and held daily stand-ups and Retrospective 3.

Progress Check: 100% of the planned work for this sprint is finished.

Effort Breakdown:

• Tasks Planned: 16
• Tasks Finished: 16

This subchapter documents the outcome of sprint 4.

The following Table 15 shows the outcome of sprint 4.

Sprint 4 Summary:

Main Achievements:

• Completed the Interim Report and Interim Presentation, including the Background/Related Work and Project Development chapters.
• Finalized Schematics Version 2 and conducted Retrospective 4.
• Held daily stand-up meetings to track progress.

Progress Check: ~89% of the planned work for this week is finished; the Chapter Project Management item remains in progress.

Effort Breakdown:

• Tasks Planned: 9
• Tasks Finished: 8

This subchapter documents the outcome of sprint 5.

The following Table 16 shows the outcome of sprint 5.

Sprint 5 Summary:

Main Achievements:

• Finalized and handed in the Interim Report and produced Schematics Version 3.
• Built the Website and Application Prototype, and created the power budget table.
• Conducted Retrospective 5; the Chapter Project Management item remains in progress.

Progress Check: ~89% of the planned work for this sprint is finished; Chapter Project Management is still in progress.

Effort Breakdown:

• Tasks Planned: 8
• Tasks Finished: 7

Scope Changes: TRAQ-164 (Table of power budget) was added after sprint start, increasing commitment by 1.5 story points (total 33.5).

This subchapter documents the outcome of sprint 6.

The following Table 17 shows the outcome of sprint 6.

Sprint 6 Summary:

Main Achievements:

• Produced the 3D model video, Leaflet, and Poster, and fixed the report after the interim feedback.
• Reviewed the Smart System schematics, added the video, and checked the lab for pieces.
• Held daily stand-ups and Retrospective 6; Chapter Project Management remains in progress.

Progress Check: ~92% of the planned work for this sprint is finished; Chapter Project Management is still in progress.

Effort Breakdown:

• Tasks Planned: 12
• Tasks Finished: 11

This subchapter documents the outcome of sprint 7.

The following Table 18 shows the outcome of sprint 7.

Sprint 7 Summary:

Main Achievements:

• Developed packing solutions and finalized the list of materials and components.
• Advanced the Paper, refined the 3D video with additional details, and completed the video add.
• Held daily stand-ups and Retrospective 7; Chapter Project Management remains in progress.

Progress Check: ~73% of the planned work for this sprint is finished; Chapter Project Management, Packing solutions, and Paper remained open at sprint close.

Effort Breakdown:

• Tasks Planned: 11
• Tasks Finished: 8

This subchapter documents the outcome of sprint 8.

The following Table 19 shows the outcome of sprint 8.

Sprint 8 Summary:

Main Achievements:

• Built the 3D Model and established costs for the aluminum bottle and plastic.
• Delivered the interim report after feedback, reviewed the Excel lists, and progressed the Paper and packing solutions.
• Held daily stand-ups and Retrospective 8; Chapter Project Management remains in progress.

Progress Check: ~82% of the planned work for this sprint is finished; Chapter Project Management and Paper remained open at sprint close.

Effort Breakdown:

• Tasks Planned: 11
• Tasks Finished: 9

This subchapter documents the outcome of sprint 9.

The following Table 20 shows the outcome of sprint 9.

Sprint 9 Summary:

Main Achievements:

• Completed 3D printing, hardware configuration, and the user Manual.
• Fixed the packing poster and progressed the Paper and App.
• Held daily stand-ups and Retrospective 9; Chapter Project Management remains in progress.

Progress Check: ~82% of the planned work for this sprint is finished; Chapter Project Management, Paper, and App remained open at sprint close.

Effort Breakdown:

• Tasks Planned: 11
• Tasks Finished: 8

This subchapter documents the outcome of sprint 10.

The following Table 21 shows the outcome of sprint 10.

Sprint 10 Summary:

Main Achievements:

• Conducted the stress test and test of components, and completed soldering work.
• Handed in the paper overview and finalized the App and Paper.
• Held Retrospective 10; Chapter Project Management remains in progress.

Progress Check: ~88% of the planned work for this sprint is finished; Chapter Project Management is still in progress.

Effort Breakdown:

• Tasks Planned: 8
• Tasks Finished: 7

This subchapter documents the outcome of sprint 11.

The following Table 22 shows the outcome of sprint 11.

Sprint 11 Summary:

Main Achievements:

• Ran the Simulation and completed the power supply adjustment and UV-C Light work.
• Reviewed paper feedback, polished the report, and fixed typos in the test report and plan.
• Held daily stand-ups and Retrospective 11; Chapter Project Management remains in progress.

Progress Check: ~91% of the planned work for this sprint is finished; Chapter Project Management is still in progress.

Effort Breakdown:

• Tasks Planned: 11
• Tasks Finished: 10

This subchapter documents the outcome of sprint 12.

The following Table 23 shows the outcome of sprint 12.

Sprint 12 Summary:

Main Achievements:

• Prepared the Final Presentation, report summary, and per-chapter conclusions.
• Mounted the UV-C light for assisted testing and addressed report comments.
• Held the Retrospective; Chapter Project Management remains in progress.

Progress Check: ~88% of the planned work for this sprint is finished; Chapter Project Management is still in progress.

Effort Breakdown:

• Tasks Planned: 8
• Tasks Finished: 7

Scope Changes: TRAQ-220 (Retrospective) was added after sprint start.

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 in Figure 19 showed the teams' different education backgrounds and speed, 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 (Figure 20) underlines less issues then the first sprint. The team also wrote what they will be improving inside the retrospective.

Retrospective 3 in Figure 21 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 4 in Figure 22 was before the Easter break. The team now is getting ready for their interim report. No major issues faces the team will contact directly teachers regarding certain documents.

Retrospective 5 (Figure 23) took place after the interim report hand-in and presentation, with Max absent. The team agreed that the sprint went well overall: the interim report, the presentation, and all related deliverables were finished on time, and communication remained good throughout the Easter break despite the team not meeting in person due to the vacation. The main concern raised was workload distribution — the team relied heavily on Bernardo to finish tasks that were originally assigned to other members, and the conclusion was that every team member should take responsibility for completing their own tasks on time. No major blockers were identified, and the team felt ready going into the next sprint.

Retrospective 6 (Figure 24) was held after the interim presentation, with Maria absent. The team reported strong overall progress: the schematics were finalized, the mistakes identified during the interim presentation were addressed, and the report was fixed based on teacher feedback. Task distribution was praised, with the team noting they had even managed to get a head start on upcoming work. Two recurring issues were raised: slow response times from teachers on Teams and email — particularly regarding lab equipment access — which had blocked progress in previous sprints as well, and inconsistent task updates on Jira from some members, making it harder for the team to track who was working on what. As an improvement point, the team suggested starting to think concretely about the prototype design and build, and committed to keeping each other better updated on task progress.

Retrospective 7 in Figure 25 was held with Inès absent. The team reported continued strong progress: tasks were being completed on schedule, the teachers were happy with the project's direction, and components were being ordered. The sprint also covered planning for the physical assembly of the bottle and early ideas for product packaging. Several improvement points were raised: task distribution and coordination could still be better, communication around absences and progress updates needed to improve — with some members announcing absences too late or not updating the team on their work — and component links should be checked and verified before weekly meetings to avoid delays. The team also noted that since lessons are now less frequent, internal progress updates need to happen more regularly to compensate. The packaging strategy was identified as the next area to focus on.

Restrospective 8 in Figure was held with Inès absent. The team reported good overall progress: tasks were completed on schedule, the teachers were satisfied with the project’s direction, and most parts of the report had already been approved. Several improvement points were identified. Communication was weaker during the holiday break, and the team agreed that more regular progress updates are needed. Some inconsistencies in poster designs were also noted, highlighting the need for a more unified visual style. In addition, tasks and deliverables for the rest of the semester should be divided more clearly so everyone knows their responsibilities. Delays with STL files and issues with materials provided by the teachers were also mentioned as challenges during the sprint.

Retrospective 9 in Figure 27 was held with Maria absent. The team reported strong technical progress during the sprint: the prototype advanced significantly, the application was successfully connected to the hardware, most sensors were functioning, and the 3D design was completed and ready for printing. The team also received the project components and was finally able to begin working with the physical sensors. Teachers were satisfied with the project’s direction and overall progress. Several challenges were also identified. Some incorrect components were delivered, which affected the initial electrical system design, and the approaching prototype deadline created additional pressure on the team. Workload distribution was mentioned multiple times as an area for improvement, with some members experiencing a heavy workload depending on their technical background. The team also agreed that communication about weekly progress should improve further.

Retrospective 10 in Figure 28 highlighted strong overall progress, with the team completing the planned tasks for the week and advancing significantly on both the prototype and the project documentation. Most hardware components were connected to the application, extensive testing of individual components was carried out, and the paper and manual were nearly finished. The team also noted that, compared to other groups, a large number of tasks had already been completed, and the teachers remained satisfied with the project’s direction. Several improvement points were discussed. Communication between team members could still be improved, especially regarding updates on completed work and explaining individual tasks to the rest of the group. Delays in 3D printing and ongoing testing of the UV-C system slowed down the assembly of the prototype, which was not yet completed as originally planned. Workload distribution remained uneven due to different technical backgrounds and areas of expertise. As a result, the team agreed to focus strongly on completing and assembling the prototype during the next sprint.

Retrospective 11 in Figure 29 showed that the project was close to completion, with most tasks already finished and strong progress made on the prototype assembly. The team successfully mounted the bottle base, installed the hardware components, and documented component measurements and testing values in the project wiki. Teamwork remained positive, the planned tasks for the week were completed, and the teachers continued to be satisfied with the project’s progress. Some challenges were still identified. Testing of the UV-C light remained delayed due to safety concerns, limited equipment, and the lack of a suitable laboratory environment. The limited 12 V power supply also created constraints for battery usage during testing. Delays in final prototype validation highlighted the need for a clearer testing procedure for the UV-C system. Additionally, presentation skills and communication remained personal improvement points for some team members.

This chapter described how the TRAQUA project was planned, organised, and managed from start to finish. Using an agile Scrum framework with weekly sprints, the team structured its work around a Jira backlog, milestone-driven prioritisation, and regular ceremonies — planning, stand-ups, retrospectives, and demos — that kept progress aligned with the deliverable deadlines defined in the project plan.

The twelve sprints reveal a clear evolution in the team's process. Early sprints showed a recurring “late-crunch” pattern, where most work was completed in a short window near the end of each cycle, and commitment regularly exceeded the work actually delivered. As shown in the velocity chart (30), the gap between committed and completed story points was widest in the middle sprints but narrowed considerably toward the end of the project: in the final sprints the completed work closely matched the commitment, indicating that the team's estimation and planning matured over time. The team settled at an average velocity of roughly 29 story points per sprint.

The retrospectives were central to this improvement. Recurring issues — uneven workload distribution stemming from the team's mixed technical backgrounds, late absence notices, inconsistent Jira updates, and slow external feedback — were identified and acted upon, including a revised Definition of Done that restored burndown accuracy after Sprint 3. Risk management and procurement were handled proactively, with early ordering and backup suppliers limiting the impact of component delays.

Overall, the project was delivered on schedule and met its milestones, and the team finished with a markedly more predictable and disciplined process than it began with. With the product developed and the project successfully managed, the next chapter turns to the marketing plan, examining how TRAQUA could be positioned and brought to market.