Differences

This shows you the differences between two versions of the page.

--- report:prm [2026/06/09 19:18] – [3.4. Quality] team5
+++ report:prm [2026/06/14 18:22] (current) – [3.10.1 Sprint 3 Outcome] team5
@@ Line 18: / Line 18: @@
 ==== 3.1. Scope ====
-Defining the scope of CONNECT is essential for keeping our efforts focused on the project's objectives: reducing digital isolation and enhancing the passenger experience within the Metro do Porto. By mapping out exactly what is included in the project, we can prevent scope creep and ensure every team member understands the roadmap from conceptualization to final development.
+Defining the scope of CONNECT and share is essential for keeping our efforts focused on the project's objectives: reducing digital isolation and enhancing the passenger experience within the Metro do Porto. By mapping out exactly what is included in the project, we can prevent scope creep and ensure every team member understands the roadmap from conceptualization to final development.
 The Work Breakdown Structure (WBS) seen in the Figure {{ref>WBS}} ilustrates how we have divided the project into manageable phases and specific deliverables.
@@ Line 139: / Line 139: @@
 This section details both the anticipated and actual expenditures incurred during the
-development of the Connect prototype. Tracking financial performance against initial
+development of the CONNECT and share prototype. Tracking financial performance against initial
 projections allows the team to detect inefficiencies early, justify spending decisions,
 and demonstrate fiscal responsibility within the constraints set by the project brief.
@@ Line 145: / Line 145: @@
 == 3.3.1. Ideal Product Cost ==
-This section outlines the projected costs for a full-scale, production-ready deployment
+This section outlines the projected costs for a full-scale, production-ready deployment of CONNECT and share across a single metro carriage: 11 handrail nodes, 7 power supply units, and
-of Connect across a single metro carriage: 11 handrail nodes, 7 power supply units, and
 ceiling LED strip runs.
@@ Line 169: / Line 168: @@
 </table>
-Hardware costs per carriage total 727.59 €, with the Polyamide (PA) Rail enclosure being the single most expensive line item at 138.60 € for two units, specified due to its fire-resistance properties required for compliance with metro safety standards. No equivalent Portuguese-based supplier was identified at the time of writing, with the current source located in France. At scale, per-unit hardware costs could be reduced through bulk procurement across multiple carriage deployments.
+Hardware costs per carriage total 764.74 €, with the Polyamide (PA) Rail enclosure being the single most expensive line item at 138.60 € for two units, specified due to its fire-resistance properties required for compliance with metro safety standards. No equivalent Portuguese-based supplier was identified at the time of writing, with the current source located in France. At scale, per-unit hardware costs could be reduced through bulk procurement across multiple carriage deployments.
 == 3.3.2. Prototype Cost ==
@@ Line 176: / Line 175: @@
 using university fabrication facilities, so the line item covers filament material only.
 Measurement and testing instruments were obtained on loan from the university laboratory,
-with no associated purchase cost. Table {{ref>tlabelPlannedCosts}} presents total list and pricing of components for the prototype. Planned cost is 3.55 € below budget ceiling (100 €).
+with no associated purchase cost. Table {{ref>tlabelPlannedCosts}} presents total list and pricing of components for the prototype. Planned cost is 2,63 € below budget ceiling (100 €).
 <table tlabelPlannedCosts>
@@ Line 190: / Line 189: @@
 | Velostat | Piezoresistive sheet (pressure sensor) | 2 | 7.90 | 15.80 |
 | CAN Transceiver | MCP2551-I/P | 2 | 1.99 | 3.98 |
-| LED strip (addressable RGB) | WS2813 IP65, 60 LEDs/m, 1m | 1 | 11.27 | 11.27 |
+| LED strip (addressable RGB) | WS2813 IP65, 60 LEDs/m, 2m | 1 | 11.27 | 11.27 |
 | Barrel jack adapter | DC female 5.5×2.1mm screw terminal | 1 | 0.92 | 0.92 |
 | Power supply | 5 VDC 4 A 20 W, 5.5×2.1mm | 1 | 11.75 | 11.75 |
@@ Line 207: / Line 206: @@
 To quantify the success of our work, we have established specific metrics and acceptance thresholds. As seen in Table {{ref>tab:quality}} each deliverable is associated with a measurable requirement.
-The selected quality metrics focus on three dimensions: technical functionality, user experience, and project completeness. This ensures that Connect is not only operational, but also meaningful and usable in its intended social context.
+The selected quality metrics focus on three dimensions: technical functionality, user experience, and project completeness. This ensures that CONNECT and share is not only operational, but also meaningful and usable in its intended social context.
 <table tab:quality>
 <caption>Quality Requirements and Metrics</caption>
@@ Line 234: / Line 233: @@
 | **5. Marketing** | 5.1 Flyer | Create brochure | Visual appeal | Professional, non-pixelated design |
 | | 5.2 Leaflet | Explain the project | Message clarity | Passengers understand it instantly |
-| | 5.3 Poster | Design poster | Impact on the Metro | Visible colors and CONNECT logo |
+| | 5.3 Poster | Design poster | Impact on the Metro | Visible colors and CONNECT and share logo |
 | | 5.4 Marketing Video | Record promotion | Promo quality | Fluid image and engaging message |
 | | 5.5 3D Model Video | Show the interior | Technical fidelity | Internal mechanism is clearly visible |
@@ Line 250: / Line 249: @@
 </table>
-To quantify the success of our work at the product level, we have established specific metrics and acceptance thresholds for the physical and digital architecture of CONNECT. As seen in Table 8, each technical subsystem and deliverable is associated with a measurable requirement. The selected quality metrics focus on three dimensions: hardware stability, network communication, and software performance. This ensures that the Connect prototype is not only operationally sound under railway simulation constraints but also structurally safe and robust for real-world user interaction.
+To quantify the success of our work at the product level, we have established specific metrics and acceptance thresholds for the physical and digital architecture of CONNECT and share. As seen in Table {{ref>tab:product_metrics}}, each technical subsystem and deliverable is associated with a measurable requirement. The selected quality metrics focus on three dimensions: hardware stability, network communication, and software performance. This ensures that the CONNECT and share prototype is not only operationally sound under railway simulation constraints but also structurally safe and robust for real-world user interaction.
-<table tab:product quality metrics>
+<table tab:product_metrics>
 <caption>Product Quality Requirements and Metrics</caption>
 <WRAP center round box 1200px>
@@ Line 300: / Line 299: @@
 | | 4.4 QR APP | Validate that 100% of scanned quick response paths trigger immediate HTTP 200 routing to the production landing URL. |
 | **5. Marketing** | 5.1 Flyer | Verify that all visual assets are exported with a professional graphic density of at least 300 DPI. |
-| | 5.2 Leaflet | Measure that non-technical testers can decode the core CONNECT value proposition within $< 10$ seconds. |
+| | 5.2 Leaflet | Measure that non-technical testers can decode the core CONNECT and share value proposition within $< 10$ seconds. |
-| | 5.3 Poster | Ensure the corporate CONNECT logo identity remains perfectly legible from a physical distance of at least 3 meters. |
+| | 5.3 Poster | Ensure the corporate CONNECT and share logo identity remains perfectly legible from a physical distance of at least 3 meters. |
 | | 5.4 Marketing Video | Render a full high-definition video track (1080p @ 60fps) with audio levels normalized strictly to -14 LUFS. |
 | | 5.5 3D Video | Display 100% of internal mechanism structures, including PCB positioning and internal CAN Bus network pathways. |
@@ Line 314: / Line 313: @@
 | | 7.5 Paper | Verify 100% structural layout compliance against the mandatory IEEE / academic conference publishing template. |
 | | 7.6 Manual | Measure a success rate $> 90\%$ for independent, non-technical users attempting to operate the system using the step-by-step instructions. |
+</WRAP>
+</table>
+Similarly, to verify the physical and digital architecture of the product without repeating project management milestones, Table {{ref>tab:product_verification}} provides the specific verification checklist for the technical deliverables of CONNECT and share. These product-level questions serve as the final engineering gate before hardware deployment.
+<table tab:product_verification>
+<caption>Product Verification Sheets for Deliverables</caption>
+<WRAP center round box 1200px>
+^ WP ^ Deliverable (WBS) ^ Necessary Steps (Checklist) ^
+| **3. Design** | 3.1 Main Ceiling Housing | Do all physical fabrication dimensions of the printed enclosure stay within a ± 1 mm tolerance band when measured against the Fusion 360 CAD model? |
+| | 3.2 Pole Secondary Node | Does the localized structural tension remain below 10% of the material yield strength under a 100 N distributed load during SimScale FEA testing? |
+| | 3.3 Enclosure Materials | Do the structural housing compounds and internal wire insulation layers carry official V-0 (UL94) flammability or LSHF certifications under standard EN 45545-2? |
+| **4. Development** | 4.1 Central Node PCB | Does the output voltage of the central node power rail maintain a stable 5.0 V ± 0.1 V output under a continuous 100% white LED brightness load? |
+| | 4.2 Sensor Node PCB | Does the analog sensor conditioning circuit maintain an absolute 0.00 V baseline on the ESP32 ADC pin when the Velostat grip is completely idle? |
+| | 4.3 LED Strip Array | Does the digital data line driven by the MCU reach a signal amplitude high enough (VIH ≥ 3.5 V) to completely eliminate high-frequency pixel flickering? |
+| | 4.4 CAN Bus Network | Does the communication interface achieve a Packet Delivery Ratio (PDR) ≥ 99.9% when transmitting 1000 consecutive data frames under simulated engine EMI? |
+| | 4.5 Interaction Firmware| Does the standby electrical current consumption of the distributed nodes drop below < 15 mA during interrupt-driven deep-sleep states? |
+| | 4.6 QR Web Application | Does the production database API route achieve a 0.0% failure rate when subjected to a heavy load test of 1000 concurrent write operations? |
+| | 4.7 AI Moderation Layer | Does the server backend automatically reject 100% of toxic, harmful, or offensive message strings with an immediate HTTP 400 bad request error? |
+| **6. Testing** | 6.1 System Response Time| Is the total end-to-end delay between the physical touch contact and the visual LED trail ignition strictly under < 100 ms when analyzed at 240 FPS? |
+| | 6.2 Ergonomic Usability | Do ≥ 80% of non-technical sample passengers instinctively locate and successfully trigger the handrail interaction area in ≤ 5 seconds? |
+| | 6.3 System Usability Scale| Does the final calculated mean score from the 10-item System Usability Scale (SUS) survey sit comfortably above the industry baseline (> 68)? |
 </WRAP>
 </table>
@@ Line 319: / Line 340: @@
 /* //Enumerate all people relevant to your project, including the project team and key stakeholders. Document their roles and responsibilities. Document your stakeholder management plan and strategy.// */
-To make CONNECT a success, it is necessary to strategically manage all parties affected by the project. Following the PMBOK standards, this section identifies the key individuals and groups, defines their roles and outlines the management strategy.
+To make CONNECT and share and share a success, it is necessary to strategically manage all parties affected by the project. Following the PMBOK standards, this section identifies the key individuals and groups, defines their roles and outlines the management strategy.
 == 3.5.1. Project Team and Internal Dynamics ==
@@ Line 341: / Line 362: @@
 | **Metro do Porto** | External client | Provides the operational context and establishes security and infrastructure standards. |
 | **Security Department (Metro)** | Regulatory body | Validates that the handle complies with fire, electrical, and physical safety regulations. |
-| **Metro do Porto Users** | Target group | Live the CONNECT experience during their commutes and provide feedback. |
+| **Metro do Porto Users** | Target group | Live the CONNECT and share experience during their commutes and provide feedback. |
 | **Suppliers** | Suppliers | Responsible for the timely delivery of components. |
 | **Legal** | Regulatory compliance | Guarantees that the QR app and data management comply with European regulations. |
@@ Line 395: / Line 416: @@
-To ensure CONNECT's success, communication is key. A communication strategy has been established to guarantee alignment between team members, supervisors and stakeholders.
+To ensure CONNECT and share's success, communication is key. A communication strategy has been established to guarantee alignment between team members, supervisors and stakeholders.
@@ Line 435: / Line 456: @@
 /*Identify key risks (product and project level), evaluate them and define how they should be handled (responses) and monitored. Perform quantitative and qualitative risk analysis and use the results to define the appropriate risk responses.*/
-Risk management for CONNECT involves a systematic approach to identify and address potential challenges. Following the PMBOK standards, we have performed qualitative analyses to ensure that risks are treated effectively.
+Risk management for CONNECT and share involves a systematic approach to identify and address potential challenges. Following the PMBOK standards, we have performed qualitative analyses to ensure that risks are treated effectively.
 == 3.7.1. Identification of Key Risks ==
@@ Line 506: / Line 527: @@
 ==== 3.8. Procurement ====
-The Connect procurement strategy balances regulated industrial components with cost-effective prototyping through centralized purchasing and institutional resource utilization. All components are sourced with a primary supplier and a defined fallback to ensure prototype assembly is not blocked by availability issues.
+The CONNECT and share procurement strategy balances regulated industrial components with cost-effective prototyping through centralized purchasing and institutional resource utilization. All components are sourced with a primary supplier and a defined fallback to ensure prototype assembly is not blocked by availability issues.
 === 3.8.1. Sources ===
@@ Line 658: / Line 679: @@
   * **Inicial sketches of our project idea**
-Bellow, we can see Table {{ref>sprint_reports}}, where we can find all Burn Down Chart from Sprint 3, with the which was first sprint managed in Jira.
-<table sprint_reports>
+=== 3.10.1 Sprint 3 Outcome ===
-<caption>Reports of sprint exported from Jira</caption>
+As illustrated in Figure {{ref>sprint3}}, the Sprint 3 Burndown Chart captures our very first agile tracking cycle and the initial progress trends of the team.
-<WRAP center round box 600px>
-^ Sprint ^ Report Link ^
+<WRAP centeralign>
-| Sprint 3 | {{ :report:sprint_3_report.pdf | Sprint 3 Report}} |
+<figure sprint3>
-| Sprint 4 | {{ :report:sprint_4_report.pdf | Sprint 4 Report}} |
+{{ :report:sprint_3.png?800 |}}
+<caption>Sprint 3 Outcome </caption>
+</figure>
 </WRAP>
-</table>
-== 3.10.1 Sprint 3 Outcome ==
 In Sprint 3 we consolidated both the technical foundation of the project and the supporting documentation. The team completed all planned issues in Jira, with no carry‑over work. Key outcomes included updated structural drawings and schematics (V2), the cardboard model, and a refined selection of materials and components. We also advanced the digital side with Figma designs for the message application and progressed written deliverables such as the background/related work and eco‑efficiency measures. Routine work like daily meetings, the sprint retrospective, and logbook updates was completed, ensuring the project stayed aligned and well documented.
-== 3.10.2 Sprint 4 Outcome ==
+  * **Why the velocity report/burndown looks like this:** Being our first sprint managed in Jira, the chart reflects initial planning chaos. The scope (red line) suddenly spiked mid-sprint because we committed the mistake of scope creep, adding major deliverables like the Cardboard Model and V2 designs on the fly instead of locking the backlog on day one.
-In Sprint 4 we advanced both the written deliverables and the technical foundations of the CONNECT system. The team completed the core report chapters (Introduction, Background & Related Work, Marketing Plan, Eco‑Efficiency Measures, Ethical & Deontological Concerns) and updated the project wiki start page, ensuring the documentation is coherent and aligned with the project vision. On the technical side, we produced Structural Drawings V3 with measurements, Detailed Schematics V3, a general software flow chart, and updated the list of materials and components, while also finalizing the clickable web app prototype and the design system/brand guidelines. Routine process tasks such as daily meetings, the sprint retrospective, and logbook updates were completed, keeping communication and traceability strong. Some higher‑effort items like Chapter 3 – Project Management, Chapter 7 – Project Developments, and the Interim Presentation remained in progress and will be continued in Sprint 5.
+  * **The Good and the Bad (Why we didn't complete 100%):** The bad habit was a prolonged flatline at zero due to last-minute status changes; the team was working in the lab but forgot to update Jira progressively. On the good side, a powerful final surge allowed us to bulk-update and close the core technical foundations just before the deadline.
+  * **Retrospective & Group Dynamic:** We realized that our initial estimations were pure guesswork due to a lack of historical data. For the next cycles, we officially banned adding any new tasks once a sprint is active and established a strict rule for real-time status updates.
+=== 3.10.2 Sprint 4 Outcome ===
+To analyze our development velocity during the middle phase of development, Figure {{ref>sprint4}} outlines the task execution line and workload behavior for Sprint 4.
+<WRAP centeralign>
+<figure sprint4>
+{{ :report:sprint_4.png?800 |}}
+<caption>Sprint 4 Outcome </caption>
+</figure>
+</WRAP>
+In Sprint 4 we advanced both the written deliverables and the technical foundations of the CONNECT and share system. The team completed the core report chapters (Introduction, Background & Related Work, Marketing Plan, Eco‑Efficiency Measures, Ethical & Deontological Concerns) and updated the project wiki start page, ensuring the documentation is coherent and aligned with the project vision. On the technical side, we produced Structural Drawings V3 with measurements, Detailed Schematics V3, a general software flow chart, and updated the list of materials and components, while also finalizing the clickable web app prototype and the design system/brand guidelines. Routine process tasks such as daily meetings, the sprint retrospective, and logbook updates were completed, keeping communication and traceability strong. Some higher‑effort items like Chapter 3 – Project Management, Chapter 7 – Project Developments, and the Interim Presentation remained in progress and will be continued in Sprint 5.
+  * **Why the velocity report/burndown looks like this:** In Sprint 4, we grew overly ambitious and massive overestimation took place, setting a giant baseline of over 110 Story Points. The scope stayed flat, but our completed work (green line) shows that we finished barely 50% of what we promised, revealing a clear bottleneck in our velocity.
+  * **The Good and the Bad (Why we didn't complete 100%):** The bad part was a severe technical roadblock: our hardware team hit a logic level nightmare with the WS2813 LED strips and the ESP32 (3.3V vs 5V logic), which paralyzed firmware progression. The good part was that we successfully advanced massive blocks of written documentation and finalized the clickable web app prototype layout.
+  * **Retrospective & Group Dynamic:** The team learned a harsh lesson about technical dependencies. We agreed that high-risk hardware integrations must be prioritized early in the sprint and assigned fewer story points to general documentation to balance the workload.
+=== 3.10.3 Sprint 5 Outcome ===
+The tracking data exported from Jira in Figure {{ref>sprint5}} displays the evolution of our remaining effort during Sprint 5, highlighting a noticeable stagnation phase.
+<WRAP centeralign>
+<figure sprint5>
+{{ :report:sprint_5.png?800 |}}
+<caption>Sprint 5 Outcome </caption>
+</figure>
+</WRAP>
+  * **Why the velocity report/burndown looks like this:** The burndown line shows a flat zero progress for the first full week of the cycle, followed by mid-sprint scope changes where the red line expanded. We suffered a noticeable completion gap, leaving nearly a third of the story points completely uncompleted at the deadline.
+  * **The Good and the Bad (Why we didn't complete 100%):** The bad side was a total drop in group momentum due to the Easter holidays. The festive break and travel schedules completely destabilized our operational cadence. On the good side, our high resilience allowed the team to reunite immediately after the break to front-load effort, pushing structural drawings (V3) and detailed schematics over the line.
+  * **Retrospective & Group Dynamic:** We recognized that statutory holidays can completely break the project flow if tasks are not scheduled around them. We determined that for future holiday periods, we must front-load deliverables or officially downscale the sprint capacity beforehand to align with real availability.
+=== 3.10.4 Sprint 6 Outcome ===
+In Figure {{ref>sprint6}}, the generated sprint report uncovers a pronounced flatline pattern that dominated the majority of our Sprint 6 tracking timeline.
+<WRAP centeralign>
+<figure sprint6>
+{{ :report:sprint_6.png?800 |}}
+<caption>Sprint 6 Outcome </caption>
+</figure>
+</WRAP>
+  * **Why the velocity report/burndown looks like this:** This chart shows an extreme case of "Student Syndrome" flatlining. The green line stays flat at zero points for almost the entire duration of the sprint, showing a single sharp vertical drop on the absolute final day to clear less than half of the total commitment.
+  * **The Good and the Bad (Why we didn't complete 100%):** The bad element was a severe communication breakdown regarding task ownership, leading to multiple team members waiting for others to finish pre-requisite components. The good aspect was that the work completed, although late, successfully cleared critical low-power firmware states and standby current optimizations.
+  * **Retrospective & Group Dynamic:** We realized that unassigned tasks in the backlog lead to total operational paralysis. The group enforced a strict retrospective rule: every single active Jira task must have a clear individual owner and explicit sub-tasks before a sprint is cleared to launch.
+=== 3.10.5 Sprint 7 Outcome ===
+Figure {{ref>sprint7}} presents the real-world metrics from our seventh sprint iteration, demonstrating how technical challenges affected our daily work logging.
+<WRAP centeralign>
+<figure sprint7>
+{{ :report:sprint_7.png?800 |}}
+<caption>Sprint 7 Outcome </caption>
+</figure>
+</WRAP>
+  * **Why the velocity report/burndown looks like this:** The chart displays an erratic scope line at the start and another flatline spanning the entire middle week. While we managed to increase our overall velocity compared to past weeks, we still faced a major deficit at the close of the cycle.
+  * **The Good and the Bad (Why we didn't complete 100%):** The bad habit was our ongoing resistance to daily logging, keeping task updates confined to the weekend. On the positive side, the hardware team successfully mitigated floating ADC noise on the Velostat sensor by validating the new mechanical housing, which unblocked the core input conditioning firmware.
+  * **Retrospective & Group Dynamic:** We resolved to schedule mandatory, physical co-working sessions instead of relying on individual remote tracking.
+=== 3.10.6 Sprint 8 Outcome ===
+The graphic evaluation provided in Figure {{ref>sprint8}} highlights the operational changes made during Sprint 8, where a downscaled scope strategy was implemented.
+<WRAP centeralign>
+<figure sprint8>
+{{ :report:sprint_8.png?800 |}}
+<caption>Sprint 8 Outcome </caption>
+</figure>
+</WRAP>
+  * **Why the velocity report/burndown looks like this:** In Sprint 8, we significantly lowered our target capacity to roughly 32 Story Points. The burndown line looks slightly better, showing an early step-down drop before flatlining in the middle and concluding with a small final delivery gap.
+  * **The Good and the Bad (Why we didn't complete 100%):** The good part is that lowering our scope allowed the team to breathe and focus on quality, achieving a much higher completion percentage. The bad part was that a critical dependency on the cork housing assembly delayed our physical integration, preventing a perfect 100% completion rate.
+  * **Retrospective & Group Dynamic:** This sprint proved that downscaling our capacity based on historical reality was the correct management choice. We decided to keep our sprint targets realistic rather than over-promising unachievable milestones to the supervisors.
+=== 3.10.7 Sprint 9 Outcome ===
+As detailed in Figure {{ref>sprint9}}, the sprint history reveals a more progressive and steady downward burn of tasks, indicating a maturation of team logging discipline.
+<WRAP centeralign>
+<figure sprint9>
+{{ :report:sprint_9.png?800 |}}
+<caption>Sprint 9 Outcome </caption>
+</figure>
+</WRAP>
+  * **Why the velocity report/burndown looks like this:** This chart reflects an improved, more progressive downward trend in the green line during the mid-sprint phase, breaking our traditional flatline habit, though a sudden late scope increase slightly altered the final tracking margin.
+  * **The Good and the Bad (Why we didn't complete 100%):** The good habit was that the team finally began updating Jira tasks mid-week, reflecting true daily laboratory efforts.
+  * **Retrospective & Group Dynamic:** Our group velocity finally started to show predictable patterns. The retrospective focus centered on padding out our software testing windows, acknowledging that external API integrations always introduce unpredictable delays.
+=== 3.10.8 Sprint 10 Outcome ===
+Figure {{ref>sprint10}} details the workload distribution and steep final steps that occurred during the closing phase of Sprint 10 as assembly deadlines neared.
+<WRAP centeralign>
+<figure sprint10>
+{{ :report:sprint_10.png?800 |}}
+<caption>Sprint 10 Outcome </caption>
+</figure>
+</WRAP>
+  * **Why the velocity report/burndown looks like this:** This burndown shows a very slow start with a sudden, massive vertical drop on the absolute last day. The scope line was modified with late additions towards the end of the timeline, pushing our target limits.
+  * **The Good and the Bad (Why we didn't complete 100%):** The bad side was a return to bulk-updating tasks at the last minute due to the rush of preparing final project deliverables.
+  * **Retrospective & Group Dynamic:** With the final presentations approaching, group dynamics shifted into high-pressure execution mode. We learned that while last-minute rushes deliver results, they compromise our tracking accuracy, highlighting the need for better stress distribution across the weeks.
+=== 3.10.9 Sprint 11 Outcome ===
+The final metrics dashboard visualized in Figure {{ref>sprint11}} displays our optimal burndown alignment, matching our most efficient development cycle.
+<WRAP centeralign>
+<figure sprint11>
+{{ :report:sprint_11.png?800 |}}
+<caption>Sprint 11 Outcome </caption>
+</figure>
+</WRAP>
+  * **Why the velocity report/burndown looks like this:** Sprint 11 shows a highly progressive step-like burndown chart, displaying clear, active drops across the middle days of the cycle. Although a late scope expansion was introduced, the green line closely followed the ideal directive slope.
+  * **The Good and the Bad (Why we didn't complete 100%):** The great success was that we achieved our highest task completion rate of the semester, successfully stabilizing the CAN Bus network and locking down the QR web application routing. The only negative aspect was that minor presentation formatting details had to be pushed to Sprint 12.
+  * **Retrospective & Group Dynamic:** This sprint proved that breaking down tasks into granular pieces (under 5 story points) yields excellent tracking metrics and constant progress. The group dynamic reached full agile maturity just in time for the final project closeout.
+=== 3.10.10 Sprint 12 Outcome ===
+Figure {{ref>sprint12}} presents the tracking metrics and burndown trend from Sprint 12, highlighting the critical challenges faced by the team during the late-stage integration phase.
+<WRAP centeralign>
+<figure sprint12>
+{{ :report:sprint_12.png?800 |}}
+<caption>Sprint 12 Outcome </caption>
+</figure>
+</WRAP>
+  * **Why the velocity report/burndown looks like this:** The chart shows a severe execution gap, where we completed less than 50% of our planned tasks (reaching only around 17 Story Points out of 38). Furthermore, the scope (red line) shows unexpected increases both at the very beginning and at the absolute deadline, proving that we suffered from late-stage scope creep by adding unplanned emergency tasks on the fly.
+  * **The Good and the Bad (Why we didn't complete 100%):** When combining the hardware and software systems, we discovered critical bugs, communication lags, and power instability that flatlined our progress (green line) between June 4th and June 8th. The good side was that once these technical bottlenecks were unblocked, the team achieved an acceleration during the final days to rescue the core data routing features.
+  * **Retrospective & Group Dynamic:** We realized that leaving complex integrations for the next sprint was a high-risk management mistake. In our retrospective, we decided that the final cycle (Sprint 13) must be completely locked with zero new features, dedicating 100% of our remaining capacity to fixing small things and perfecting the final presentation.
 ==== 3.11. Sprint Evaluations ====