This chapter details the project management methodologies and organizational frameworks applied throughout the development of the project. It outlines the team's approach to structuring, executing, and monitoring the workload using an Agile framework organized into 15 distinct sprints.

It covers:

• Scope & Time Management: Definition of the product and project boundaries, alongside schedule management, key milestones, and visual timelines mapping project phases to deadlines.
• Cost & Quality: An overview of the budget allocation, financial tracking (planned versus effective costs), and the quality metrics and thresholds established to evaluate project deliverables.
• People, Stakeholders & Communications: Identification of team roles, responsibilities, stakeholder engagement strategies, and the internal communication channels that guided the group.
• Risk & Procurement: The identification, analysis (quantitative and qualitative), and mitigation of product and project-level risks, alongside sourcing strategies and make-versus-buy decisions.
• Project Plan: A structural breakdown of the project timeline, detailing the Global Sprint Plan, the comprehensive Project Backlog, and the distribution of Epics across the project lifecycle.
• Sprint Outcomes & Evaluations: A review of sprint backlogs, planned capacity versus achieved velocity, and summaries of sprint retrospectives that drove the team's continuous improvement strategy.

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 1 ilustrates how we have divided the project into manageable phases and specific deliverables.

The EPS teams have to complete a list of milestones to ensure project succes. The following Table 1 defines the project timeline, acting as the baseline to monitor the project's performance.

The timeline reveals a strong concentration of deliverables in April and May, particularly around the interim report and prototype development phases. This required careful sprint planning to balance documentation and technical implementation tasks.

This section details both the anticipated and actual expenditures incurred during the 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.

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 3 ceiling LED strip runs.

Table 2 presents the planned ideal product hardware costs.

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.

All components were procured through a single supplier (Mauser) to consolidate shipping and avoid duplicate delivery charges. The 3D-printed PLA enclosure was produced 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 3 presents total list and pricing of components for the prototype. Planned cost is 2,63 € below budget ceiling (100 €).

Quality management is needed to ensure that every deliverable meets the technical requirements and the expectations of our primary stakeholders: Porto Metro passengers and EPS coordination. Following the Project Management Body of Knowledge (PMBOK) standards, quality is managed as a continuous process rather than a final check. By defining clear metrics and verification protocols, we minimize risks and guarantee that the final prototype is safe, functional and socially impactful.

To quantify the success of our work, we have established specific metrics and acceptance thresholds. As seen in Table 4 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 and share is not only operational, but also meaningful and usable in its intended social context.

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 5, 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.

While metrics define “what” we want to achieve, our verification system ensures “how” we check it. Table 6 presents a series of Yes/No questions for every deliverable. These sheets act as a final quality gate: if the answer to the question is “Yes”, the deliverable is accepted.

Similarly, to verify the physical and digital architecture of the product without repeating project management milestones, Table 7 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.

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.

We operate under a structure where all members share responsibility for project management. However, as we are a team of students with diverse backgrounds, special tasks are delegated based on individual expertise.

Using the weekly sprint plan helps us to redistribute tasks if a member is overburdened to prevent burnout and ensure quality.

Apart from the main teams, several external entities are involved in the project. In the Table 8 below, we identified them, their roles and their responsibilities.

Among all stakeholders, Metro do Porto, the Security Department (Metro), and end users are considered critical, as they directly influence feasibility, approval, and user acceptance.

To manage these relationships effectively, we have analyzed each stakeholder based on their Power and Interest. This analysis allows us to prioritize our communication and engagement efforts.

A) POWER/INTEREST MATRIX

The following matrix, seen in the Figure 2, categorizes our stakeholders into four quadrants to determine the necessary level of engagement for each group.

B) ENGAGEMENT STRATEGY TABLE

While the matrix identifies the “where”, the following Table 9 defines the “how”. It establishes the specific strategy for each group and assigns a point person from the internal team to manage the relationship.

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.

The team uses multiple tools to maintain a continuous flow of information:

• WhatsApp: Used for urgent, informal and daily communication.
• Microsoft Teams: Serves as the primary repository for all project documentation. Also for remote meetings.
• Jira: Used to track the backlog, manage sprints and assign tasks to team members.
• Miro: A digital whiteboard used during brainstorming sessions.
• Outlook: Reserved for formal communication with external stakeholders, suppliers and ISEP coordinators.

Table 10 presents our activities and the way of realization, covering the frequency, medium, and participants involved in each communication event throughout the project.

We maintain a specific communication frequency with external parties:

• ISEP Supervisors: Weekly feedback sessions every Thursday to ensure the project meets academic requirements.
• Target Users: Feedback gathered through surveys and testing sessions.

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.

We have identified the following risks categorized into project and product levels.

PROJECT LEVEL RISKS:

• Delivery: Delays in receiving components
• Financial Constraint: Exceeding the budget due to component value or price fluctuations
• Team Synchronicity: misalignment in tasks leading to delays in the final assembly

PRODUCT LEVEL RISKS:

• Safety Rejection: Failure to meet safety standards
• Vandalism: Intentional damage or theft of the internal electronics
• Environmental Durability: Material degradation
• Cybersecurity: QR code spoofing
• Power Supply Instability: Failure of the internal battery or power management system during long commutes
• Ergonomic Strain: The handle design causing discomfort or safety issues for passengers
• Privacy Breach: Unauthorized collection or exposure of user data through the interaction app.

To evaluate these risks, we adopt a 5×5 Risk Matrix seen on the Figure 3. The exposure score is calculated by multiplying Probability (1-5) and Impact (1-5).

Probability Scale: 1 (Rare) to 5 (Almost Certain)

Impact Scale: 1 (Insignificant) to 5 (Severe)

EXPOSURE LEVELS:

• Low (1-3): Acceptable; minimal monitoring.
• Moderate (4-6): Manageable; requires routine control.
• High (8-12): Significant; requires a specific mitigation plan.
• Extreme (15-25): Critical; requires immediate action and response.

The risk analysis highlights that logistical and physical risks (delivery and vandalism) pose the greatest threat to project success, like it is shown in Figure 11.

Based on the results, our strategy prioritizes Extreme and High risks. Delivery (R1) and Vandalism (R5) require immediate mitigation through early procurement and robust mechanical design.

For safety and privacy risks (R4, R10) and avoidance strategy is mandatory. We ensure the project is never at risk of legal or institutional rejection by following external regulations.

All secondary risks are monitored through iterative testing to detect any score escalation.

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.

Three procurement streams are defined:

• Primary Hardware (Buy): Electronic components including microcontrollers (Wemos C3 Mini), WS2813 LED strips, MCP2551 CAN transceivers, and resistors are sourced from Mauser.pt, chosen for its Portuguese presence, competitive pricing, and reliable lead times. In the event Mauser.pt cannot fulfill an order, the fallback suppliers are Mouser Electronics (mouser.com) and Worten (worten.pt), both of which stock equivalent or pin-compatible parts and ship to Portugal within 3 to 5 business days.
• Specialty Materials (Buy): Nanovia PA Rail filament is procured directly from the manufacturer, as it is the only identified EN 45545-2 compliant fire-retardant filament certified for metro rail applications. No equivalent Portuguese supplier exists. Should Nanovia be unavailable or delivery be delayed, the fallback is Polymaker PC-FR or BASF Ultrafuse FR filament, which carry comparable fire-retardancy ratings and are available through 3DJake.com or Filamento.pt with shorter regional lead times.
• Fabrication (Make): Enclosures are 3D printed using ISEP laboratory facilities, reducing cost to raw material only. If ISEP printers are unavailable, a local print service such as Fablab Porto or an online service such as Craftcloud can produce parts from supplied STL files within 2 to 4 days.

The following Table 12 summarizes the strategic choices for key project elements.

Expenditure is tracked against a detailed bill of materials within the program budget constraints. Component procurement is milestone-gated to ensure availability before prototype assembly begins. For each line item, the primary supplier, unit price, and quantity required are recorded in the BOM alongside the identified fallback supplier and its estimated lead time differential. Miscellaneous passive components are sourced locally where possible to reduce lead times. If a primary supplier quotes a lead time exceeding five business days at a critical milestone, the fallback supplier is activated without waiting for the primary order to fail.), both of which stock equivalent or pin-compatible parts and ship to Portugal within 3 to 5 business days.

• Specialty Materials (Buy): Nanovia PA Rail filament is procured directly from the manufacturer, as it is the only identified EN 45545-2 compliant fire-retardant filament certified for metro rail applications. No equivalent Portuguese supplier exists. Should Nanovia be unavailable or delivery be delayed, the fallback is Polymaker PC-FR or BASF Ultrafuse FR filament, which carry comparable fire-retardancy ratings and are available through 3DJake.com or Filamento.pt with shorter regional lead times.
• Fabrication (Make): Enclosures are 3D printed using ISEP laboratory facilities, reducing cost to raw material only. If ISEP printers are unavailable, a local print service such as Fablab Porto or an online service such as Craftcloud can produce parts from supplied STL files within 2 to 4 days.

As detailed in the Global Sprint Plan (see 13), the project is divided into 15 distinct sprints.

The specific tasks and deliverables assigned to these periods are managed in the Project Backlog (see Table 14).

The high-level distribution of Epic responsibilities across the timeline is summarized in the Initial Sprint Plan (see Table15).

Lastly, the visual dependencies and duration of these tasks are illustrated in the Gantt Chart (see Figure 4).

Sprints 1 & 2 were not managed in Jira and there were no specific tasks to be done. However, the idea of the project had been forming before Sprint 3 and some outcomes were achieved such as:

• Black Box Diagram V1
• Structural Drawings V1
• Selection of materials and components V1
• Inicial sketches of our project idea

As illustrated in Figure 5, the Sprint 3 Burndown Chart captures our very first agile tracking cycle and the initial progress trends of the team.

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.
• 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.

To analyze our development velocity during the middle phase of development, Figure 6 outlines the task execution line and workload behavior for Sprint 4.

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.

The tracking data exported from Jira in Figure 7 displays the evolution of our remaining effort during Sprint 5, highlighting a noticeable stagnation phase.

• 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.

In Figure 8, the generated sprint report uncovers a pronounced flatline pattern that dominated the majority of our Sprint 6 tracking timeline.

• 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.

Figure 9 presents the real-world metrics from our seventh sprint iteration, demonstrating how technical challenges affected our daily work logging.

• 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.

The graphic evaluation provided in Figure 10 highlights the operational changes made during Sprint 8, where a downscaled scope strategy was implemented.

• 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.

As detailed in Figure 11, the sprint history reveals a more progressive and steady downward burn of tasks, indicating a maturation of team logging discipline.

• 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.

Figure 12 details the workload distribution and steep final steps that occurred during the closing phase of Sprint 10 as assembly deadlines neared.

• 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.

The final metrics dashboard visualized in Figure 13 displays our optimal burndown alignment, matching our most efficient development cycle.

• 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.

Figure 14 presents the tracking metrics and burndown trend from Sprint 12, highlighting the critical challenges faced by the team during the late-stage integration phase.

• 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.

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.

In this sprint, the focus was on establishing the technical foundation. The retrospective revealed significant gaps in task granularity and time management.
Retrospective Summary:

• Positive (+): Effective feedback loops with professors and proactive note-taking during presentations.
• Negative (-): Vague backlog items, inconsistent Jira updates, and poor workload distribution.
• Action Plan: The team committed to breaking down tasks into sub-tasks (max 4h each) and ensuring Jira is updated daily.

Following the action plan from the previous sprint, Sprint 4 showed a marked improvement in organization and team morale.

Retrospective Summary:

• Positive (+): High motivation, excellent mutual support, and a much more balanced task distribution.
• Negative (-): No major process blockers identified; the workflow reached a stable state.
• Action Plan: Focus on maintaining the current communication frequency and standardizing the documentation style for the upcoming deliverables.

Sprint 5 centered on the team's first formal presentation. The retrospective highlighted strong collaboration and timely delivery, but identified gaps in presentation rehearsal and logistics.

Retrospective Summary:

• Positive (+): Strong mutual support, high motivation, timely task completion, and a well-received presentation.
• Negative (-): Last-minute changes to slides and script, lack of in-person group rehearsal, and unclear stage roles and transitions.
• Action Plan: The team agreed to freeze presentation content 24 hours before the deadline, schedule a mandatory in-person dry run, and explicitly assign stage positions and slide control responsibilities during planning.

Sprint 6 focused on production of key deliverables, including the promotional video, 3D model, and marketing materials. The retrospective reflected strong output but flagged recurring carry-over as an area for improvement.

Retrospective Summary:

• Positive (+): Clear task ownership, consistent progress on the web app, and successful completion of major deliverables including the video and 3D model.
• Negative (-): Some tasks carried over across multiple sprints, indicating insufficient task breakdown during planning.
• Action Plan: The team committed to decomposing tasks into smaller, more manageable steps from the outset of each sprint to reduce carry-over.

Sprint 7 saw the completion of several key deliverables and continued web app progress. The retrospective identified procrastination as the main obstacle to a smoother workflow.

Retrospective Summary:

• Positive (+): Clear task division, steady web app progress, and successful completion of the provider list, materials list, video, and 3D model.
• Negative (-): Procrastination led to tasks being completed later in the sprint than planned.
• Action Plan: The team committed to starting tasks earlier in each sprint cycle to maintain a more consistent workload distribution.

Sprint 8 we had strong team cohesion and worked efficient with tasks. The retrospective identified no significant areas for improvement.

Retrospective Summary:

• Positive (+): Strong collaboration and communication across the team, clear task ownership, and well-balanced workload distribution.
• Negative (-): No process issues identified.
• Action Plan: The team agreed to maintain the current working dynamic and communication standards going forward.

Sprint 9 delivered comunication/visual material that received good feedback and continued web app progress, but exposed workflow gaps tied to component delays and tasks that carried over several sprints.

Retrospective Summary:

• Positive (+): Positive supervisor feedback, completion of the leaflet, poster, and visual materials, and continued steady progress on the web app.
• Negative (-): Several tasks carried over across multiple sprints, and prototype work was blocked pending component delivery.
• Action Plan: The team committed to improving workflow oversight to better anticipate blockers and prevent task accumulation.

Sprint 10 was a stable sprint with most tasks completed as expected. The team acknowledged the need to pick up the pace as the project deadline draws closer.
Retrospective Summary:

• Positive (+): Tasks were mostly completed as planned.
• Negative (-): The team recognized the need to work more intensively in the final sprints.
• Action Plan: The team committed to increasing the work pace to meet final deadlines.

Sprint 11 featured a successful marketing pre-presentation and good team communication. Carrying over tasks remained as an ongoing challenge.
Retrospective Summary:

• Positive (+): Successful marketing pre-presentation and strong team communication.
• Negative (-): Some tasks carried over across multiple sprints.
• Action Plan: The team committed to breaking tasks into smaller steps from the start of each sprint so they don’t carry over several sprints.

  3.12. Summary

  This chapter detailed the management strategies used to organize and track the project's progress. We established the core foundations for scope, time, and cost, while also setting up protocols for quality, risk, and procurement. Managing communications and stakeholders was also key to keeping the workflow consistent and transparent.

These management pillars are put into practice through a cycle of continuous planning and execution. The Sprint outcomes and evaluations documented here reflect our ongoing effort to refine the workflow and hit project milestones. With the management structure in place, the focus now shifts to the Marketing Plan to define the project's market strategy and value proposition.