report:prm

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
report:prm [2026/06/14 15:37] team5report:prm [2026/06/14 18:22] (current) – [3.10.1 Sprint 3 Outcome] team5
Line 692: Line 692:
 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. 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.
  
-  * **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.+  * **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.
   * **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.   * **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.   * **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.
Line 820: Line 820:
  
 === 3.10.10 Sprint 12 Outcome === === 3.10.10 Sprint 12 Outcome ===
-Figure {{ref>sprint12}} +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> <WRAP centeralign>
 <figure sprint12> <figure sprint12>
 {{ :report:sprint_12.png?800 |}} {{ :report:sprint_12.png?800 |}}
 +
 <caption>Sprint 12 Outcome </caption> <caption>Sprint 12 Outcome </caption>
 </figure> </figure>
 </WRAP> </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.10.11 Sprint 13 Outcome === 
-Figure {{ref>sprint13}}  
  
-<WRAP centeralign> 
-<figure sprint13> 
-{{ :report:sprint_13.png?800 |}} 
-<caption>Sprint 13 Outcome </caption> 
-</figure> 
-</WRAP> 
 ==== 3.11. Sprint Evaluations ==== ==== 3.11. Sprint Evaluations ====
 Sprint evaluations and retrospectives are fundamental to the team’s Agile workflow, allowing for continuous process improvement. Starting from Sprint 3, the team implemented formal retrospective sessions to identify bottlenecks and refine internal methodologies. Sprint evaluations and retrospectives are fundamental to the team’s Agile workflow, allowing for continuous process improvement. Starting from Sprint 3, the team implemented formal retrospective sessions to identify bottlenecks and refine internal methodologies.
  • report/prm.1781447844.txt.gz
  • Last modified: 2026/06/14 15:37
  • by team5