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/04/15 18:57] – [Quality] epsatisepreport:prm [2026/04/30 22:58] (current) – [3.11.7 Seventh retrospective - 2026-04-23] team1
Line 1: Line 1:
 ===== 3. Project Management ===== ===== 3. Project Management =====
 +
 /*Provide here an overview of the contents (structure) of this chapter. Explain the project management approach your group followed and justify why you think it is a good approach.*/ /*Provide here an overview of the contents (structure) of this chapter. Explain the project management approach your group followed and justify why you think it is a good approach.*/
  
 This chapter presents the project management approach adopted for the development of Screen2Green. Since the project combines hardware development, software integration, user interaction, and academic reporting within a limited timeframe, it required a management strategy capable of balancing structure with flexibility. This chapter presents the project management approach adopted for the development of Screen2Green. Since the project combines hardware development, software integration, user interaction, and academic reporting within a limited timeframe, it required a management strategy capable of balancing structure with flexibility.
- 
  
 To address this, the team adopted a hybrid project management approach combining elements of Scrum and Waterfall. Waterfall was useful for planning around fixed academic deadlines and mandatory deliverables established by the EPS programme, while Scrum supported iterative development, continuous feedback, and adaptation to technical and organizational challenges throughout the semester. This combination was considered appropriate because the project contains both predictable elements, such as milestone submissions, and uncertain elements, such as concept refinement, prototype development, and system integration. To address this, the team adopted a hybrid project management approach combining elements of Scrum and Waterfall. Waterfall was useful for planning around fixed academic deadlines and mandatory deliverables established by the EPS programme, while Scrum supported iterative development, continuous feedback, and adaptation to technical and organizational challenges throughout the semester. This combination was considered appropriate because the project contains both predictable elements, such as milestone submissions, and uncertain elements, such as concept refinement, prototype development, and system integration.
- 
  
 The chapter is organized into the main areas relevant to project management: scope, time, cost, quality, people and stakeholder management, communication, risk, procurement, and project plan. Together, these sections explain how the team structured the work, allocated responsibilities, monitored progress, and responded to challenges during the project. The chapter is organized into the main areas relevant to project management: scope, time, cost, quality, people and stakeholder management, communication, risk, procurement, and project plan. Together, these sections explain how the team structured the work, allocated responsibilities, monitored progress, and responded to challenges during the project.
  
-==== Scope ====+ 
 +==== 3.1 Scope ==== 
 /*Document the boundaries of your project. Document the product scope (the extent of what your project will produce) and the project Scope (summary of the work needed to produce it). Make sure you clearly define what is part of the project and what is outside of its scope, justifying as needed.*/ /*Document the boundaries of your project. Document the product scope (the extent of what your project will produce) and the project Scope (summary of the work needed to produce it). Make sure you clearly define what is part of the project and what is outside of its scope, justifying as needed.*/
  
 The scope of the project defines both the product to be developed and the work required to deliver it. In the case of Screen2Green, the main goal is to design and develop a functional prototype of a pot system that links smartphone screen-time behaviour to the condition of a living basil plant. The scope of the project defines both the product to be developed and the work required to deliver it. In the case of Screen2Green, the main goal is to design and develop a functional prototype of a pot system that links smartphone screen-time behaviour to the condition of a living basil plant.
- 
  
 From a product perspective, the scope includes the development of a compact indoor plant-growing system capable of supporting basil cultivation in a small residential environment. The system is intended to include a physical pot structure, a water reservoir, an automated irrigation mechanism, a microcontroller-based control system, and a mobile application that communicates relevant information to the user. The core concept of the product is that excessive screen-time affects the watering conditions of the plant, thereby creating a physical and biological feedback loop. The prototype is expected to demonstrate the feasibility of this concept rather than function as a market-ready consumer product. From a product perspective, the scope includes the development of a compact indoor plant-growing system capable of supporting basil cultivation in a small residential environment. The system is intended to include a physical pot structure, a water reservoir, an automated irrigation mechanism, a microcontroller-based control system, and a mobile application that communicates relevant information to the user. The core concept of the product is that excessive screen-time affects the watering conditions of the plant, thereby creating a physical and biological feedback loop. The prototype is expected to demonstrate the feasibility of this concept rather than function as a market-ready consumer product.
  
- +From a project perspective, the scope includes all activities necessary to research, design, develop, and document the prototype, as shown in Figure {{ref>WBS}}, which presents the Work Breakdown Structure (WBS) for the project. This involves background research such as indoor herb cultivation, hydroponics, smartphone usage and mental health. It also includes concept generation, selection of materials and components, development of hardware and software, testing, evaluation, and the production of all required academic deliverables, such as the report, presentations, poster, flyer, and supporting documentation.
-From a project perspective, the scope includes all activities (see Figure {{ref>WBS}} for the Work Breakdown Structure for the project) necessary to research, design, develop, and document the prototype. This involves background research such as indoor herb cultivation, hydroponics, smartphone usage and mental health. It also includes concept generation, selection of materials and components, development of hardware and software, testing, evaluation, and the production of all required academic deliverables, such as the report, presentations, poster, flyer, and supporting documentation. +
- +
  
 <WRAP centeralign> <WRAP centeralign>
Line 29: Line 26:
 </WRAP> </WRAP>
  
 +The scope of the project is intentionally limited. The team does not aim to develop a fully commercialized product, a large-scale production model, or a fully finished mobile application with advanced features. Similarly, the project does not include large-scale user trials, long-term biological validation, or full optimization of all environmental variables affecting plant growth, such as artificial lighting, nutrient automation, or AI-based plant monitoring. These areas are considered relevant for future development, but they are outside the scope of the current project.
  
 +Defining these boundaries was important in order to keep the project realistic and achievable within the available time, budget, and technical resources. The scope therefore reflects a proof-of-concept approach, where the team focuses on demonstrating the technical and conceptual value of the solution.
  
  
 +==== 3.2 Time ====
  
- 
-The scope of the project is intentionally limited. The team does not aim to develop a fully commercialized product, a large-scale production model, or a fully finished mobile application with advanced features. Similarly, the project does not include large-scale user trials, long-term biological validation, or full optimization of all environmental variables affecting plant growth, such as artificial lighting, nutrient automation, or AI-based plant monitoring. These areas are considered relevant for future development, but they are outside the scope of the current project. 
- 
- 
-Defining these boundaries was important in order to keep the project realistic and achievable within the available time, budget, and technical resources. The scope therefore reflects a proof-of-concept approach, where the team focuses on demonstrating the technical and conceptual value of the solution. 
-==== Time ==== 
 /*Explain how you managed the schedule of your project. Document the key milestones of your project, mapping key phases to reference deadlines.*/ /*Explain how you managed the schedule of your project. Document the key milestones of your project, mapping key phases to reference deadlines.*/
- 
  
 Time management was an essential part of the project due to the fixed deadlines established by the EPS programme. To ensure steady progress, the team organized the semester around milestone-based planning supported by iterative one-week sprints. Time management was an essential part of the project due to the fixed deadlines established by the EPS programme. To ensure steady progress, the team organized the semester around milestone-based planning supported by iterative one-week sprints.
- 
  
 The overall project schedule followed the official EPS deadlines, which served as the main milestones for deliverables and report development. These milestones helped structure the work and ensured that the team continuously aligned its progress with the expectations of supervisors and course requirements. Key deadlines included the submission of system diagrams, structural drafts, materials lists, sprint planning documents, the interim report and presentation, the final report, and the final prototype demonstration. The overall project schedule followed the official EPS deadlines, which served as the main milestones for deliverables and report development. These milestones helped structure the work and ensured that the team continuously aligned its progress with the expectations of supervisors and course requirements. Key deadlines included the submission of system diagrams, structural drafts, materials lists, sprint planning documents, the interim report and presentation, the final report, and the final prototype demonstration.
- 
  
 In addition to milestone-based planning, the team organized the work into weekly sprints beginning every Thursday. This sprint structure made it possible to divide the project into smaller and more manageable increments. Each sprint focused on a specific set of goals, such as research, concept refinement, deliverable completion, app development, or preparation for presentations. This approach supported regular evaluation of progress and allowed the team to identify problems earlier than would have been possible with a purely linear planning model. In addition to milestone-based planning, the team organized the work into weekly sprints beginning every Thursday. This sprint structure made it possible to divide the project into smaller and more manageable increments. Each sprint focused on a specific set of goals, such as research, concept refinement, deliverable completion, app development, or preparation for presentations. This approach supported regular evaluation of progress and allowed the team to identify problems earlier than would have been possible with a purely linear planning model.
- 
  
 At the beginning of each sprint, tasks were selected and prioritized based on upcoming deadlines, dependencies, and team capacity. As the project evolved, the team improved its sprint planning process by introducing more structured meetings and clearer task organization. From sprint 3 onward, regular Scrum meetings were held three times a week, on Friday, Monday, and Wednesday. During these meetings, each member reported what had been completed, what would be worked on next, and whether any blockers had appeared. These meetings contributed to stronger coordination and better short-term planning. At the beginning of each sprint, tasks were selected and prioritized based on upcoming deadlines, dependencies, and team capacity. As the project evolved, the team improved its sprint planning process by introducing more structured meetings and clearer task organization. From sprint 3 onward, regular Scrum meetings were held three times a week, on Friday, Monday, and Wednesday. During these meetings, each member reported what had been completed, what would be worked on next, and whether any blockers had appeared. These meetings contributed to stronger coordination and better short-term planning.
- 
  
 The main project milestones are presented in Table {{ref>project_milestones}}. The main project milestones are presented in Table {{ref>project_milestones}}.
- 
  
 <WRAP center round box 60%> <WRAP center round box 60%>
Line 77: Line 65:
 | 2026-06-23    | Final corrections and upload of refined deliverables   | | 2026-06-23    | Final corrections and upload of refined deliverables   |
 | 2026-06-25    | Prototype demonstration and final submission   | | 2026-06-25    | Prototype demonstration and final submission   |
- 
 </table> </table>
 </WRAP> </WRAP>
- 
  
 Although the sprint-based structure improved flexibility, the team initially experienced difficulties with task definition, prioritization, and maintaining an overview of progress in Jira. Some tasks were completed without being updated in the system, while others were too vaguely defined to support efficient planning. Over time, these issues were reduced by reorganizing Jira, improving communication, and refining the way tasks were categorized and assigned. As a result, time management became more consistent and better aligned with the project’s pace and complexity. Although the sprint-based structure improved flexibility, the team initially experienced difficulties with task definition, prioritization, and maintaining an overview of progress in Jira. Some tasks were completed without being updated in the system, while others were too vaguely defined to support efficient planning. Over time, these issues were reduced by reorganizing Jira, improving communication, and refining the way tasks were categorized and assigned. As a result, time management became more consistent and better aligned with the project’s pace and complexity.
  
  
-==== Cost ====+==== 3.3 Cost ==== 
 /*Describe your project budget and its key components. Explain how your budget was managed throughout the project. Document the planned vs. effective costs of your project.*/ /*Describe your project budget and its key components. Explain how your budget was managed throughout the project. Document the planned vs. effective costs of your project.*/
  
 The project isdeveloped as a prototype and therefore followed a limited-budget approach (100 €). The main objective of the cost management process was to ensure that the essential functionality of the Screen2Green system could be achieved using affordable and accessible components, while still maintaining sufficient technical quality for prototyping and testing. The project isdeveloped as a prototype and therefore followed a limited-budget approach (100 €). The main objective of the cost management process was to ensure that the essential functionality of the Screen2Green system could be achieved using affordable and accessible components, while still maintaining sufficient technical quality for prototyping and testing.
- 
  
 The main cost drivers in the project are the electronic and structural components required to build the prototype. These include the microcontroller, water pump, sensors, tubing, reservoir materials, structural materials for the pot, and power-related components. The main cost drivers in the project are the electronic and structural components required to build the prototype. These include the microcontroller, water pump, sensors, tubing, reservoir materials, structural materials for the pot, and power-related components.
- 
  
 A preliminary estimate of the prototype cost is presented in Table {{ref>components_and_materials}} . A preliminary estimate of the prototype cost is presented in Table {{ref>components_and_materials}} .
- 
  
 /*Needs to be updated*/ /*Needs to be updated*/
Line 115: Line 99:
 |Total estimated prototype cost| 43.99 | |Total estimated prototype cost| 43.99 |
 </table> </table>
- 
  
 The estimated total cost of the current component list is 43.99 €, which can be rounded to 44.00 €. This indicates that the prototype can be developed at a relatively low direct material cost, which supports the project’s goal of creating an accessible and feasible concept for small-scale indoor use. The estimated total cost of the current component list is 43.99 €, which can be rounded to 44.00 €. This indicates that the prototype can be developed at a relatively low direct material cost, which supports the project’s goal of creating an accessible and feasible concept for small-scale indoor use.
- 
  
 To manage costs responsibly, the team selected standard off-the-shelf components from accessible suppliers and aimed to reduce unnecessary complexity in the system design. This approach helps keep the prototype within a realistic academic budget while still allowing for functional testing and system integration. In a future commercial version of the product, the cost structure would need to be expanded to include manufacturing, packaging, distribution, and software development costs. To manage costs responsibly, the team selected standard off-the-shelf components from accessible suppliers and aimed to reduce unnecessary complexity in the system design. This approach helps keep the prototype within a realistic academic budget while still allowing for functional testing and system integration. In a future commercial version of the product, the cost structure would need to be expanded to include manufacturing, packaging, distribution, and software development costs.
  
-==== Quality ====+ 
 +==== 3.4 Quality ==== 
 /*Document quality metrics that will apply to your project deliverables, associated thresholds and how they should be reviewed.*/ /*Document quality metrics that will apply to your project deliverables, associated thresholds and how they should be reviewed.*/
  
 Quality management in this project focuses on ensuring that the prototype, documentation, and associated deliverables meet the expected technical and academic standards. Because Screen2Green combines both physical and digital elements, quality must be evaluated across multiple dimensions, including functionality, usability, reliability, and documentation quality. Quality management in this project focuses on ensuring that the prototype, documentation, and associated deliverables meet the expected technical and academic standards. Because Screen2Green combines both physical and digital elements, quality must be evaluated across multiple dimensions, including functionality, usability, reliability, and documentation quality.
- 
  
 The most important quality criterion for the prototype is functional feasibility. The system must demonstrate the intended relationship between smartphone usage behaviour and plant care through a working technical concept. This includes successful interaction between the mobile application, the control system, and the watering mechanism. In addition, the prototype must operate safely and consistently under controlled conditions. The most important quality criterion for the prototype is functional feasibility. The system must demonstrate the intended relationship between smartphone usage behaviour and plant care through a working technical concept. This includes successful interaction between the mobile application, the control system, and the watering mechanism. In addition, the prototype must operate safely and consistently under controlled conditions.
- 
  
 A second important quality dimension is usability. Since the product is intended for non-technical users, the concept must remain understandable, intuitive, and manageable in a home environment. This concerns both the physical design of the pot and the communication of feedback through the app. A third quality dimension is reliability, particularly regarding the watering mechanism, communication between system components, and the prevention of water-related technical issues. A second important quality dimension is usability. Since the product is intended for non-technical users, the concept must remain understandable, intuitive, and manageable in a home environment. This concerns both the physical design of the pot and the communication of feedback through the app. A third quality dimension is reliability, particularly regarding the watering mechanism, communication between system components, and the prevention of water-related technical issues.
  
- +In order to assess quality, the team defined the general metrics listed in Table {{ref>quality_metrics}}.
-In order to assess quality, the team defined the general metrics in Table {{ref>quality_metrics}}:+
  
 <table quality_metrics> <table quality_metrics>
Line 145: Line 126:
 |Documentation quality|Chapters complete, coherent, and aligned with requirements|Internal review and supervisor feedback| |Documentation quality|Chapters complete, coherent, and aligned with requirements|Internal review and supervisor feedback|
 </table> </table>
-==== People & Stakeholder Management ====+ 
 + 
 +==== 3.5 People & Stakeholder Management ==== 
 /*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.*/ /*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.*/
  
  
-Because Screen2Green is a multidisciplinary project, effective people and stakeholder management was necessary to ensure coordinated progress and balanced contributions. The team consists of six students from different academic fields and national backgrounds, which provided the project with a broad range of competencies, including mechanical engineering, applied computer technology, electronics and ICT, media technology, industrial product design, and security-related technical knowledge. This diversity was a major strength of the project, as it allowed the team to approach the problem from multiple perspectives.+=== 3.5.1 Introduction ===
  
 +The objective of this Stakeholder Management is to identify, classify, and analyze the individuals and organizations involved in the Smart Pot project. For this project, which aims to reduce user screen time through a physical connection to a plant and an automated watering system, managing stakeholders is vital to balance technical feasibility with user well-being goals.
  
-At the same time, differences in academic background, communication style, and preferred working methods also created challenges. Team members approached tasks with different expectations regarding structure, level of detail, and pace of execution. For this reason, it was important to define roles, distribute responsibilities, and create routines that improved alignment over time.+Because Screen2Green is a multidisciplinary project, effective people and stakeholder management is necessary to ensure coordinated progress and balanced contributions. The team consists of six students from different academic fields and national backgrounds, which provided the project with a broad range of competencies, including mechanical engineering, applied computer technology, electronics, media technology, industrial product design, and security-related technical knowledge. This diversity was a major strength of the project, as it allowed the team to approach the problem from multiple perspectives. At the same time, differences in academic background, communication style, and preferred working methods also created challenges. Team members approached tasks with different expectations regarding structure, level of detail, and pace of execution. For this reason, it was important to define roles, distribute responsibilities, and create routines that improved alignment over time.
  
  
-The main stakeholders in the project include the project team itself, the teachers and supervisors at ISEP, and the potential end users of the solution. The team members are the primary internal stakeholders, as they are directly responsible for designing, building, and documenting the system. Teachers and supervisors are key external academic stakeholders, since they provide guidance, evaluate deliverables, and influence the direction of the project through feedback. The intended end users, such as students and young adults with high screen-time usage, are also relevant stakeholders because the product is developed to address their needs and behaviour.+=== 3.5.2 Identify Stakeholders ===
  
 +To ensure no critical parties are overlooked, the team used a brainstorming methodology to identify both internal and external stakeholders. A stakeholder is defined as any person or organization that meets one of the following criteria: will be directly or indirectly affected by the Smart Pot or its companion app, holds a position that can influence project outcomes, controls resources such as funding, materials, or technical expertise, is a potential user or a competitor. The main stakeholders in the project include the project Team 1 itself, the teachers and supervisors at ISEP, and the potential end users of the solution. The team members are the primary internal stakeholders, as they are directly responsible for designing, building, and documenting the system. Teachers and supervisors are key external academic stakeholders, since they provide guidance, evaluate deliverables, and influence the direction of the project through feedback. The intended end users, such as students and young adults with high screen-time usage, are also relevant stakeholders because the product is developed to address their needs and behaviour.
  
 A stakeholder analysis helps clarify the degree of influence and interest associated with each group. In this project, supervisors and teachers can be considered key stakeholders due to their high influence and high interest. The project team also belongs to this category. Potential users have high interest but limited direct influence during the academic development process. Suppliers and external partners have lower influence and are therefore of secondary importance in the current project stage. A stakeholder analysis helps clarify the degree of influence and interest associated with each group. In this project, supervisors and teachers can be considered key stakeholders due to their high influence and high interest. The project team also belongs to this category. Potential users have high interest but limited direct influence during the academic development process. Suppliers and external partners have lower influence and are therefore of secondary importance in the current project stage.
  
  
-==== Communications ==== +=== 3.5.3 Key Stakeholders ===
-/*Document how your team will manage communications, describing communication channels, meetings, etc.*/+
  
 +Key stakeholders represent the individuals or groups who have significant influence over the project or are directly affected by its implementation.
  
-Communication played a central role in coordinating the project and maintaining progress across technical development, documentation, and planning activities. Since the team worked across multiple disciplines and perspectives, a structured communication strategy was necessary to reduce misunderstandings and improve collaboration.+For the Screen2Green project, the following stakeholders have been identified:
  
 +  * Unordered List ItemProject Team 1: These are internal stakeholders consisting of six students from diverse technical backgrounds. They are responsible for the entire project lifecycle, including the design, assembly, and documentation of the Smart Pot system.
  
-Internal communication was primarily handled through regular meetings and digital collaboration tools. Scrum meetings were introduced to ensure that members frequently updated each other on progress, priorities, and blockers. These meetings became especially important from sprint 3 onward, when the team increased their frequency to three times per week. This helped improve shared understanding and made it easier to identify issues before they became larger delays.+  * ISEP Supervisors: This group of academic stakeholders provides the necessary technical framework and guidance. They are responsible for evaluating project deliverables and ensuring the project meets university standards.
  
 +  * Young Adults: This target market group consists of the primary end users. Their needs regarding screen time reduction and user experience are the main drivers for the product's functional requirements.
  
-Jira was used as the main project management tool for planning and tracking tasks. It allowed the team to create sprint backlogs, assign responsibilities, and monitor the status of work. Google Calendar was used to maintain an overview of deadlines, milestone dates, and meetings. In addition, Microsoft Teams served as a shared workspace for deliverables, files, articles, and general documentation.+  * ISEP 3D Printing: As a technical stakeholder within the university, this department is essential for the fabrication of the physical pot components. Access to these resources directly impacts the prototyping schedule.
  
 +  * YouTube Creators: These external partners are vital for the marketing strategy. They serve as influencers who build product credibility and awareness through video content and demonstrations.
  
-Despite these structures, communication within the team was initially challenging. Differences in working styles and expectations sometimes led to inefficiencies, delayed responses, and incomplete coordination. In some cases, members completed tasks without updating their progress in Jira, which reduced transparency and made planning more difficult. To improve this situation, the team placed more emphasis on structured meetings, clearer task ownership, and more regular status updates.+  * Mauser.pt: This is the primary supplier for the project's electrical components. They provide the sensors and hardware necessary for the automatic watering system and app connectivity.
  
 +  * Online Retailers: Platforms such as Amazon and Ebay are identified as distribution stakeholders. They represent the primary channels through which the product will reach a global market.
 +
 +
 +=== 3.5.4 Stakeholder Analysis ===
 +
 +The project team utilizes the following power and interest levels to determine the most effective management strategy for each group.
 +
 +Figure {{ref>stakeholder_matrix}} shows the power/interest matrix with all the stakeholders.
 +
 +<WRAP centeralign>
 +<figure stakeholder_matrix>
 +{{ :report:screenshot_2026-04-29_at_23.16.32.jpeg?600 |}}
 +<caption>Stakeholder matrix</caption>
 +</figure>
 +</WRAP>
 +
 +The identified risks are summarized in Table {{ref>stakeholder_table}}.
 +
 +<table stakeholder_table>
 +<caption>Stakeholder matrix table</caption>
 +^ Key ^ Stakeholder ^ Organization ^ Power (1-5) ^ Interest (1-5) ^ 
 +|A|Team 1|ISEP (Internal) |5|5|
 +|B|ISEP Supervisors|ISEP (Academic)|5|4|
 +|C|Young Adults|Target Market|2|5|
 +|D|ISEP 3D Printing|ISEP (Lab)|4|2|
 +|E|YouTube Creators|Marketing Partners|2|4|
 +|F|Mauser.pt|Supplier|4|1|
 +|G|Online retailers|Amazon/Ebay|3|2|
 +</table>
 +
 +
 +==== 3.6 Communications ====
 +
 +/*Document how your team will manage communications, describing communication channels, meetings, etc.*/
 +
 +Communication played a central role in coordinating the project and maintaining progress across technical development, documentation, and planning activities. Since the team worked across multiple disciplines and perspectives, a structured communication strategy was necessary to reduce misunderstandings and improve collaboration.
 +
 +Internal communication was primarily handled through regular meetings and digital collaboration tools. Scrum meetings were introduced to ensure that members frequently updated each other on progress, priorities, and blockers. These meetings became especially important from sprint 3 onward, when the team increased their frequency to three times per week. This helped improve shared understanding and made it easier to identify issues before they became larger delays.
 +
 +Jira was used as the main project management tool for planning and tracking tasks. It allowed the team to create sprint backlogs, assign responsibilities, and monitor the status of work. Google Calendar was used to maintain an overview of deadlines, milestone dates, and meetings. In addition, Microsoft Teams served as a shared workspace for deliverables, files, articles, and general documentation.
 +
 +Despite these structures, communication within the team was initially challenging. Differences in working styles and expectations sometimes led to inefficiencies, delayed responses, and incomplete coordination. In some cases, members completed tasks without updating their progress in Jira, which reduced transparency and made planning more difficult. To improve this situation, the team placed more emphasis on structured meetings, clearer task ownership, and more regular status updates.
  
 Overall, communication management evolved during the project. While it was a challenge in the early stages, it gradually became more effective as routines were established and the team became more aligned in how information should be shared and discussed. Overall, communication management evolved during the project. While it was a challenge in the early stages, it gradually became more effective as routines were established and the team became more aligned in how information should be shared and discussed.
  
  
-==== Risk ====+==== 3.7 Risk ==== 
 /*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.*/ /*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.*/
- 
  
 The Screen2Green project involves several potential risks related to both technical and organizational aspects. Due to the combination of hardware, software, and biological elements, uncertainty is present in both system functionality and project execution. The Screen2Green project involves several potential risks related to both technical and organizational aspects. Due to the combination of hardware, software, and biological elements, uncertainty is present in both system functionality and project execution.
- 
  
 One of the main risks is technical failure, particularly related to the integration of hardware and software components. The system depends on communication between the mobile application, microcontroller, and watering mechanism. If this integration fails, the core concept of linking screen-time behaviour to plant care cannot be demonstrated. To reduce this risk, the system is to be developed in a modular way and tested incrementally throughout the project. One of the main risks is technical failure, particularly related to the integration of hardware and software components. The system depends on communication between the mobile application, microcontroller, and watering mechanism. If this integration fails, the core concept of linking screen-time behaviour to plant care cannot be demonstrated. To reduce this risk, the system is to be developed in a modular way and tested incrementally throughout the project.
- 
  
 Another significant risk is project delays, mainly caused by time constraints and task dependencies. Since the project follows fixed academic deadlines, delays in one task may affect multiple deliverables. This risk is managed through sprint planning, regular Scrum meetings, and continuous prioritization of tasks. Another significant risk is project delays, mainly caused by time constraints and task dependencies. Since the project follows fixed academic deadlines, delays in one task may affect multiple deliverables. This risk is managed through sprint planning, regular Scrum meetings, and continuous prioritization of tasks.
- 
  
 There is also a risk related to system reliability, such as inaccurate sensor readings or water leakage. These issues could affect both the functionality and safety of the prototype. To mitigate this, components are tested under controlled conditions, and design decisions are made to separate water and electronics where possible. There is also a risk related to system reliability, such as inaccurate sensor readings or water leakage. These issues could affect both the functionality and safety of the prototype. To mitigate this, components are tested under controlled conditions, and design decisions are made to separate water and electronics where possible.
- 
  
 A project-specific risk is that the plant may not respond clearly enough to changes in watering. Since the concept relies on visible feedback from the plant, limited biological response could weaken the overall impact of the solution. This risk is addressed by adjusting watering thresholds and clearly defining the prototype limitations. A project-specific risk is that the plant may not respond clearly enough to changes in watering. Since the concept relies on visible feedback from the plant, limited biological response could weaken the overall impact of the solution. This risk is addressed by adjusting watering thresholds and clearly defining the prototype limitations.
- 
  
 Organizational risks such as miscommunication and uneven workload distribution may also affect progress. These are mitigated through regular meetings, clear task allocation, and continuous collaboration within the team. Organizational risks such as miscommunication and uneven workload distribution may also affect progress. These are mitigated through regular meetings, clear task allocation, and continuous collaboration within the team.
- 
  
 The identified risks are summarized in Table {{ref>project_risks}}. The identified risks are summarized in Table {{ref>project_risks}}.
Line 217: Line 242:
 |R9|Budget limitations|Limited budget affecting component choices or prototype quality | Medium | Medium | Medium | Use cost-effective components, prioritize essential features| |R9|Budget limitations|Limited budget affecting component choices or prototype quality | Medium | Medium | Medium | Use cost-effective components, prioritize essential features|
 </table> </table>
- 
  
 To support the risk assessment, a risk matrix based on probability and impact was used (see Figure {{ref>risk_matrix}}). The matrix classifies risks into low, medium, and high categories. To support the risk assessment, a risk matrix based on probability and impact was used (see Figure {{ref>risk_matrix}}). The matrix classifies risks into low, medium, and high categories.
  
- +<table risk_matrix> 
-<WRAP center round box 60%> +<caption>Risk matrix</caption>
-<figure risk_matrix>+
 {{ :report:risk_matrix.png?600 |}} {{ :report:risk_matrix.png?600 |}}
-<caption>Risk matrix</caption> +</table>
-</figure> +
-</WRAP>+
  
  
 Based on this analysis, risks related to system integration, project delays, and system complexity are classified as high risk, as they have the greatest potential impact on project success. These risks require continuous monitoring and prioritization throughout the project. Based on this analysis, risks related to system integration, project delays, and system complexity are classified as high risk, as they have the greatest potential impact on project success. These risks require continuous monitoring and prioritization throughout the project.
- 
  
 Medium-level risks, such as sensor inaccuracies, water leakage, and plant response, are addressed through testing and design adjustments. Lower-level risks, including communication issues and uneven workload distribution, are managed through regular meetings, clear task allocation, and team coordination. Medium-level risks, such as sensor inaccuracies, water leakage, and plant response, are addressed through testing and design adjustments. Lower-level risks, including communication issues and uneven workload distribution, are managed through regular meetings, clear task allocation, and team coordination.
  
-==== Procurement ==== + 
-== Introduction == +==== 3.8 Procurement ==== 
 The procurement of components focuses on technical reliability within a limited budget and tight schedule to ensure that project is delivered on time. All materials are selected to ensure availability for the assembly phase. The procurement of components focuses on technical reliability within a limited budget and tight schedule to ensure that project is delivered on time. All materials are selected to ensure availability for the assembly phase.
  
-== Suppliers ==+ 
 +=== 3.8.1 Suppliers === 
 All electrical components are ordered locally from a single website: Mauser Portugal. Sourcing from one supplier ensures that all parts arrive together and reduces costs to a single shipping fee. This is necessary due to the restricted prototype budget. All electrical components are ordered locally from a single website: Mauser Portugal. Sourcing from one supplier ensures that all parts arrive together and reduces costs to a single shipping fee. This is necessary due to the restricted prototype budget.
  
 Structural parts utilize cork, which is a local material in Portugal. Using local cork supports the regional economy and reduces environmental impact from transportation. Structural parts utilize cork, which is a local material in Portugal. Using local cork supports the regional economy and reduces environmental impact from transportation.
  
-== Decision Making ==+ 
 +=== 3.8.2 Decision Making === 
 Decisions are based on budget and time limitations. It is not possible to manufacture every part within the given timeframe, like ESP32 boards. A readymade solenoid valve was selected instead of building a custom valve with a servo motor. This choice ensures a reliable, leak-proof solution and saves time during the development phase. Specific parts needed to have certain features to ensure longevity of the product like more expensive model of anticorrosion temperature sensor. Decisions are based on budget and time limitations. It is not possible to manufacture every part within the given timeframe, like ESP32 boards. A readymade solenoid valve was selected instead of building a custom valve with a servo motor. This choice ensures a reliable, leak-proof solution and saves time during the development phase. Specific parts needed to have certain features to ensure longevity of the product like more expensive model of anticorrosion temperature sensor.
-==== Project Plan ==== 
-//Document how the sprint backlog was planned and managed for each of the sprints you have created in Planner.//  
  
-The team utilizes Scrum and works with sprints of one week each. Every sprint is based around the project's deliverables, internally discussed tasks and internally discussed research topics. [[https://www.atlassian.com/software/jira|Jira]] is the utilized tool for managing Scrum with Avkaran as Scrum master. Since the team is using the free version of Jira, traditional story mapping is not possible. This is due to the following.+ 
 +==== 3.9 Project Plan ==== 
 +The team utilizes Scrum and works with sprints of one week each. Every sprint is based around the project's deliverables, internally discussed tasks and internally discussed research topics. [[https://www.atlassian.com/software/jira|Jira]] is the utilized tool for managing Scrum with Avkaran as Scrum master. Since the team is using the free version of Jira, traditional story mapping is not possible. 
 + 
 +This is due to the following: 
   * It's impossible to assign existing tasks to features.   * It's impossible to assign existing tasks to features.
     * the opposite is also impossible.     * the opposite is also impossible.
Line 261: Line 289:
  
 Figure {{ref>fig:sprintplan}} is a screenshot of the timeline on Jira. This timeline, including all the deadlines and chosen epic periods, decided the sprint plan for this project. Using different colors, the team separated epic periods with the same starting and ending date. Some epics have no specific starting or ending date, so these will go on until a final task or feature has been decided. Figure {{ref>fig:sprintplan}} is a screenshot of the timeline on Jira. This timeline, including all the deadlines and chosen epic periods, decided the sprint plan for this project. Using different colors, the team separated epic periods with the same starting and ending date. Some epics have no specific starting or ending date, so these will go on until a final task or feature has been decided.
 +
 <WRAP centeralign> <WRAP centeralign>
 <figure fig:sprintplan> <figure fig:sprintplan>
Line 274: Line 303:
 <caption>Global sprint plan</caption> <caption>Global sprint plan</caption>
 <WRAP> <WRAP>
-^ Sprint ^ Dates ^ Theme ^ # Deliverables ^ Status ^ % Done ^ +^ Sprint ^ Dates ^ Theme ^ # Deliverables ^ Status ^ Percentage of tasks done (%) ^ 
-| 1  | Mar 5 – Mar 11  | Research | 2 | Finished | 100 % | +| 1  | Mar 5 – Mar 11  | Research | 2 | Finished | 100 | 
-| 2  | Mar 12 – Mar 18 | Setting a system | 2 | Finished | 55 % | +| 2  | Mar 12 – Mar 18 | Setting a system | 2 | Finished | 55 | 
-| 3  | Mar 19 – Mar 25 | Schema, flyer & prototyping | 3 | Finished | 88.57 % | +| 3  | Mar 19 – Mar 25 | Schema, flyer & prototyping | 3 | Finished | 88.57 | 
-| 4  | Mar 26 – Apr 1  | Refining, refactoring, developing & testing | 0 | Finished | 45.16 % | +| 4  | Mar 26 – Apr 1  | Refining, refactoring, developing & testing | 0 | Finished | 45.16 | 
-| 5  | Apr 2 – Apr 8   | Refining, refactoring, developing & testing | 0 | Finished | 44.82 % | +| 5  | Apr 2 – Apr 8   | Refining, refactoring, developing & testing | 0 | Finished | 44.82 | 
-| 6  | Apr 9 – Apr 15  | Finishing the interim | 1 | In progress |  | +| 6  | Apr 9 – Apr 15  | Finishing the interim | 1 | Finished | 96.78 | 
-| 7  | Apr 16 – Apr 22 | 3D modeling | 1 | To do |  | +| 7  | Apr 16 – Apr 22 | 3D modeling and developing | 1 | Finished | 46.15 | 
-| 8  | Apr 23 – Apr 29 | Finalizing the components & materials list | 1 | To do |  | +| 8  | Apr 23 – Apr 29 | Finalizing the components & materials list | 1 | In progress | 51.16 | 
-| 9  | Apr 30 – May 6  | Refining the interim | 1 | To do |  |+| 9  | Apr 30 – May 6  | Refining the report | 1 | To do |  |
 | 10 | May 7 – May 13  | Deciding on a packaging solution | 1 | To do |  | | 10 | May 7 – May 13  | Deciding on a packaging solution | 1 | To do |  |
 | 11 | May 14 – May 20 | Refining, refactoring, developing & testing | 0 | To do |  | | 11 | May 14 – May 20 | Refining, refactoring, developing & testing | 0 | To do |  |
Line 295: Line 324:
 </WRAP> </WRAP>
  
-=== Backlog definition === 
  
-== Sprint 1: ==+=== 3.9.1 Backlog definition === 
 + 
 +== 3.9.1.1 Sprint 1: ==
  
 The first phase/sprint was solely focused on research. In order to understand the problem and define a more granular project topic, the team needed a baseline of knowledge, so the sprint consisted of only research-related tasks. The main research topics were smart farming, basil growing and the correlation between mental health and plants. The backlog included tasks for every deliverable. The first phase/sprint was solely focused on research. In order to understand the problem and define a more granular project topic, the team needed a baseline of knowledge, so the sprint consisted of only research-related tasks. The main research topics were smart farming, basil growing and the correlation between mental health and plants. The backlog included tasks for every deliverable.
  
-== Sprint 2: ==+ 
 +== 3.9.1.2 Sprint 2: ==
  
 The team's project idea didn't get accepted because it was too broad and didn't solve a specific problem. The team then made the idea to turn this into a project that helps increase productivity and motivation while working or studying. Using an app, the user can set focus sessions where successful productivity helps a plant grow by connecting the app to the smart plant grower. This grower is called the growth pod. The backlog gained design-related tasks for the coming sprint periods. The team's project idea didn't get accepted because it was too broad and didn't solve a specific problem. The team then made the idea to turn this into a project that helps increase productivity and motivation while working or studying. Using an app, the user can set focus sessions where successful productivity helps a plant grow by connecting the app to the smart plant grower. This grower is called the growth pod. The backlog gained design-related tasks for the coming sprint periods.
Line 307: Line 338:
 This sprint included research refinement tasks, research on productivity and motivation and design related tasks. Lastly, there were deliverable related tasks. The backlog gained some research topics of which we were unsure were necessary for this project. This sprint included research refinement tasks, research on productivity and motivation and design related tasks. Lastly, there were deliverable related tasks. The backlog gained some research topics of which we were unsure were necessary for this project.
  
-== Sprint 3: ==+ 
 +== 3.9.1.3 Sprint 3: ==
  
 The team's project idea got accepted. A noticeable amount of deliverables had to be finished this sprint, so most of the tasks were related to that. Apart from deliverables, there were tasks related to refining the Wiki due to a large difference in everyone's writing style. The backlog now included only deliverable related tasks and a few other tasks since most of them got transported to this sprint. The team's project idea got accepted. A noticeable amount of deliverables had to be finished this sprint, so most of the tasks were related to that. Apart from deliverables, there were tasks related to refining the Wiki due to a large difference in everyone's writing style. The backlog now included only deliverable related tasks and a few other tasks since most of them got transported to this sprint.
  
-== Sprint 4: ==+ 
 +== 3.9.1.4 Sprint 4: ==
  
 The team caught up with their missing work and everyone is on the same terms regarding the product, so now development could finally start. The sprint length was shorter than others and several members were unavailable for half the period, so there was a noticeable decrease in task weight and amount. The backlog gained a substantial amount of app development related tasks. The team caught up with their missing work and everyone is on the same terms regarding the product, so now development could finally start. The sprint length was shorter than others and several members were unavailable for half the period, so there was a noticeable decrease in task weight and amount. The backlog gained a substantial amount of app development related tasks.
  
-== Sprint 5: ==+ 
 +== 3.9.1.5 Sprint 5: ==
  
 Due to the holidays, both the sprint backlog and the global backlog have mostly remained the same. All of the team members were unavailable for the majority of the holidays. Due to the holidays, both the sprint backlog and the global backlog have mostly remained the same. All of the team members were unavailable for the majority of the holidays.
-==== Sprint Outcomes ==== + 
-=== First sprint ===+ 
 +== 3.9.1.6 Sprint 6: == 
 + 
 +The global backlog consisted of many tasks regarding the front end of the application as well as some tasks regarding deliverables, mainly the 3D model. For the app, each component got their own subset of tasks depending on depth of functionality. Finally, some new research tasks were created after discovery of interesting topics. While many tasks were created for the app, only a couple were implemented in the sprint backlog due to time needed to learn three new softwares, being Solidworks, Flutter and Supabase. In general, the sprint had very few tasks due to unavailability of some team members. 
 + 
 + 
 +== 3.9.1.7 Sprint 7: == 
 + 
 +The global backlog kept a very similar state due to unavailability in some team members, as well as more time needed to learn Solidworks and Supabase. Because of the same reason, the sprint backlog also stayed very similar except for the addition of tasks needed to create the skeletal base of the application's front end. 
 + 
 + 
 +== 3.9.1.8 Sprint 8: == 
 + 
 +Most of the front end related tasks were implemented in this sprint's backlog, meaning the global backlog had very few tasks left regarding the application. Half of the tasks in the global backlog were designated to the deliverables, while the other half consisted of tasks regarding testing, wiki chapter improvements and the plant pot which isn't in development yet. 
 + 
 + 
 +==== 3.10 Sprint Outcomes ==== 
 + 
 +=== 3.10.1 First sprint === 
 By the end of the sprint, every task was completed and the team evaluated the task weight to be a healthy number. After each member researched and reported on their given fields, the team could focus on making a sprint plan. By the end of the sprint, every task was completed and the team evaluated the task weight to be a healthy number. After each member researched and reported on their given fields, the team could focus on making a sprint plan.
  
-=== Second sprint ===+ 
 +=== 3.10.2 Second sprint === 
 The backlog consisted of tasks regarding the deliverables, subject related assignments and refactoring prior research. The reason behind the latter is because the reports were written unprofessionally and were saved in a separate environment. By the end of this sprint, all the research got refactored into the Wiki. There was an exponential growth of amount of tasks done per day, but everything was finished before the retrospective. The backlog consisted of tasks regarding the deliverables, subject related assignments and refactoring prior research. The reason behind the latter is because the reports were written unprofessionally and were saved in a separate environment. By the end of this sprint, all the research got refactored into the Wiki. There was an exponential growth of amount of tasks done per day, but everything was finished before the retrospective.
  
 The following sprints will have more focus on proper communication, this is because some tasks were done without having their status updated in Jira and because there was low engagement off-campus. The following sprints will have more focus on proper communication, this is because some tasks were done without having their status updated in Jira and because there was low engagement off-campus.
  
-=== Third sprint ===+ 
 +=== 3.10.3 Third sprint === 
 The team felt like they were behind on tasks and internal discussions, so the third sprint focused on lots of research, deliverables and internal tasks. Out of a total of 35 tasks with  considerable weight, 32 were finished and the smallest ones were transferred to next sprint. The team is extremely satisfied with how this sprint ended. Team 1 managed to finish important discussions and decide on important factors of the project, leading to everyone being on the same basis. The team felt like they were behind on tasks and internal discussions, so the third sprint focused on lots of research, deliverables and internal tasks. Out of a total of 35 tasks with  considerable weight, 32 were finished and the smallest ones were transferred to next sprint. The team is extremely satisfied with how this sprint ended. Team 1 managed to finish important discussions and decide on important factors of the project, leading to everyone being on the same basis.
  
-=== Fourth sprint ===+ 
 +=== 3.10.4 Fourth sprint === 
 Due to a shortened sprint period and several team members being unable to deliver or show progress, few tasks have been completed. This sprint was mainly focused on preparing the pre-interim presentation and starting app development. Due to the app developer being unable to work however, this got delayed to next week. Only about 60% of the tasks were completed, with the rest being transferred to sprint 5. Due to a shortened sprint period and several team members being unable to deliver or show progress, few tasks have been completed. This sprint was mainly focused on preparing the pre-interim presentation and starting app development. Due to the app developer being unable to work however, this got delayed to next week. Only about 60% of the tasks were completed, with the rest being transferred to sprint 5.
  
-=== Fifth sprint ===+ 
 +=== 3.10.5 Fifth sprint === 
 Due to the holidays, most tasks were left unfinished. The team underestimated the amount of tasks and assigned many of them before starting the sprint. Because of this, less than half of the sprint's backlog had been completed. The team has learned to take external factors such as holidays into accordance when deciding the sprint's backlog. Due to the holidays, most tasks were left unfinished. The team underestimated the amount of tasks and assigned many of them before starting the sprint. Because of this, less than half of the sprint's backlog had been completed. The team has learned to take external factors such as holidays into accordance when deciding the sprint's backlog.
-==== Sprint Evaluations ==== + 
-=== First retrospective - 2026-03-05 ===+ 
 +=== 3.10.6 Sixth sprint === 
 + 
 +Firstly, the team had an outstanding presentation in terms of preparation, information, enthusiasm and conviction. Secondly, 31 out of 32 tasks were completed. Thirdly, the team held a very progressive retrospective. 
 + 
 +The team has improved in several factors and has only one carry over task. However, the team had poor meeting etiquette on Sunday. This sprint has taught the team a lot about themselves as individuals and also as a whole. 
 + 
 + 
 +=== 3.10.7 Seventh sprint === 
 + 
 +Only half of the tasks were completed due to underestimating the learning curve of new software, Solidworks and Flutter. Since this sprint focused on programming and 3D modeling, most of the tasks were for these topics. Due to the team having only 1 app developer and 1 member with access to Solidworks, the task weight was divided in a very unbalanced manner, which lead to only a select amount of tasks being completed.  
 + 
 +This delegation has been discussed in team and the decision was that there was no other way to divide the tasks due to deliverable deadlines and personal deadlines. Secondly, due to future member unavailability, this sprint was intended to finish tasks in regard to that. 
 + 
 + 
 +=== 3.10.8 Eighth sprint === 
 + 
 +A third of the tasks this sprint were carried over from last sprint. In the end, half of the tasks were for the application's front end with some having been made for the back end. Due to sudden personal reasons and errors that asked for a lot of time to get handled, the sprint has yet again ended with unfinished tasks. Only two third of this sprint's tasks were finished in time. 
 + 
 +The team found out that task division wasn't optimal last sprint. Having the same results this sprint has lead to the team evaluating each other's tasks before starting the new sprint. The following 2 sprints will have a focus on task division. 
 +==== 3.11 Sprint Evaluations ==== 
 + 
 +=== 3.11.1 First retrospective - 2026-03-05 ===
  
 The team's first project idea got rejected, so there was little time to think about the chosen topic. The team reviewed the chosen topic and decided to research topics revolving the project as well as topics that seemed important to this project. The team's first project idea got rejected, so there was little time to think about the chosen topic. The team reviewed the chosen topic and decided to research topics revolving the project as well as topics that seemed important to this project.
Line 344: Line 427:
 Due to miscommunication however, the team presented undiscussed topics regarding the app and so gave the teachers unconfirmed information. This was addressed accordingly in the retrospective. Due to miscommunication however, the team presented undiscussed topics regarding the app and so gave the teachers unconfirmed information. This was addressed accordingly in the retrospective.
  
-=== Second retrospective - 2026-03-12 ===+ 
 +=== 3.11.2 Second retrospective - 2026-03-12 ===
  
 Due to a lack of an agenda, the team had no meeting with the teachers. Luckily, they allowed for a small feedback round. There, the team learned that the Wiki was lacking in information and that some deliverables were incomplete. Due to a lack of an agenda, the team had no meeting with the teachers. Luckily, they allowed for a small feedback round. There, the team learned that the Wiki was lacking in information and that some deliverables were incomplete.
Line 363: Line 447:
     * Procrastinate task assignment.     * Procrastinate task assignment.
  
-=== Third retrospective - 2026-03-19 ===+ 
 +=== 3.11.3 Third retrospective - 2026-03-19 ===
  
 What went well: What went well:
Line 388: Line 473:
 In general, the team is satisfied with their progress and results this sprint. They're caught up with missing work and research and each member now shares the same ideas regarding the growth pod. There is now a strong and clear baseline. In general, the team is satisfied with their progress and results this sprint. They're caught up with missing work and research and each member now shares the same ideas regarding the growth pod. There is now a strong and clear baseline.
  
-=== Fourth retrospective - 2026-04-01 ===+ 
 +=== 3.11.4 Fourth retrospective - 2026-04-01 ===
  
 What went well: What went well:
Line 403: Line 489:
   * Stop doing:   * Stop doing:
     * /     * /
-==== Summary ==== 
  
-This chapter presented the project management approach used in the development of Screen2Green, combining structured planning with iterative development. The defined scope, time planning, cost control, and risk management ensured that the project remained feasible within its constraints, while continuous improvements in communication and coordination strengthened team performance. 
  
 +=== 3.11.5 Fifth retrospective - 2026-04-09 ===
 +
 +There was no retrospective this sprint due to a similar sprint backlog and project backlog.
 +
 +
 +=== 3.11.6 Sixth retrospective - 2026-04-16 ===
 +
 +This week, the team had an interim presentation and they had to deliver an interim report. This presentation was an important moment of practice for the final product presentation and this moment was also a moment of feedback.
 +
 +What went well:
 +  * The team improved in overall communication, language skills, team confidence and individual confidence. There was minimal negative feedback on the interim report.
 +
 +What didn’t go well:
 +  * The team held a meeting on Sunday to prepare for uploading the interim deliverables. There was no engagement from certain team members and the overall energy was very low. Secondly, certain team members were unprepared.
 +
 +What should the team:
 +  * Keep doing:
 +    * Keep the same energy like in the interim presentation. The team was driven, they showed passion and the members were all on the same wavelength.
 +  * Start doing:
 +    * /
 +  * Stop doing:
 +    * Come to a meeting unprepared.
 +
 +In general, the team is very satisfied with the end result and finished almost all the tasks of this sprint. The team can now focus on the next deliverables and development.
 +
 +
 +=== 3.11.7 Seventh retrospective - 2026-04-23 ===
 +The team thought that just like in last sprint the task division was unfair and that people underestimated the weight of their tasks. 
 +
 +
 +
 +==== 3.12 Summary ====
 +
 +This chapter presented the project management approach used in the development of Screen2Green, combining structured planning with iterative development. The defined scope, time planning, cost control, and risk management ensured that the project remained feasible within its constraints, while continuous improvements in communication and coordination strengthened team performance.
  
 Overall, the project management strategy provided a solid foundation for developing a functional prototype. Based on this, the next chapter focuses on the marketing plan, where the product is analyzed in terms of market potential, target users, and strategic positioning. Overall, the project management strategy provided a solid foundation for developing a functional prototype. Based on this, the next chapter focuses on the marketing plan, where the product is analyzed in terms of market potential, target users, and strategic positioning.
 +
 +
  • report/prm.1776275855.txt.gz
  • Last modified: 2026/04/15 18:57
  • by epsatisep