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/12 11:38] – [Third retrospective - 2026-03-19:] team1report:prm [2026/05/01 17:49] (current) – [3.4 Quality] 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 Smart 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.
  
 +=== 3.1.1 Product scope ===
  
 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.
  
- +=== 3.1.2 Project scope === 
-From a project perspective, the scope includes all activities (see {{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. +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 on indoor herb cultivation, hydroponics, smartphone usage and mental health. It also includes concept development, selection of materials and electrical components, hardware assembly, software integration, system testing, and evaluation. In addition, the scope covers the production of all required academic deliverables, including the written report, presentations, poster, flyer, and supporting documentation. These activities are structured through the Work Breakdown Structure (WBS), which organizes the project into manageable components [(scope_management_plan_template)].
  
  
 +<WRAP centeralign>
 <figure WBS> <figure WBS>
 {{ :report:bwc.jpg |WBS for Screen2Green}}<caption>WBS for Screen2Green</caption> {{ :report:bwc.jpg |WBS for Screen2Green}}<caption>WBS for Screen2Green</caption>
 </figure> </figure>
 +</WRAP>
  
 +=== 3.1.3 Scope limitations and constraints ===
  
 +The scope of the project is intentionally limited in order to ensure feasibility within the constraints of a single academic semester. The project does not include the development of a market-ready product, large-scale production, or a fully featured mobile application. Advanced features such as long-term plant monitoring, artificial lighting optimization, nutrient automation, or large-scale user testing are excluded. These elements are considered potential areas for future development but fall outside the scope of the current project. The project is further constrained by limited time, budget restrictions, and the technical complexity of integrating hardware, software, and biological elements into a single system. These constraints were taken into account when defining and managing the scope, ensuring that the project remained realistic and achievable
  
  
 +=== 3.1.4 Acceptance criteria ===
  
-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.+The project is considered successful if the prototype demonstrates a functional connection between smartphone screen-time data and the plant’s watering mechanism, supports basic indoor basil growth, and allows the user to observe a clear relationship between digital behaviour and plant condition.
  
  
-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.1.5 Roles and responsibility ===
-==== Time ==== +
-/*Explain how you managed the schedule of your project. Document the key milestones of your project, mapping key phases to reference deadlines.*/+
  
 +Scope management is a shared responsibility among the six team members. Decisions related to defining and adjusting the scope are made collaboratively, taking into account technical feasibility, time constraints, and alignment with the project objectives. Supervisors contribute through regular feedback, supporting validation of the project direction and deliverables.
  
-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. 
  
 +=== 3.1.6 Scope control and verification ===
  
-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.+Scope control is an ongoing process used to monitor the status of the project scope and ensure that all work performed aligns with the defined objectives and deliverables [(scope_management_plan_template)]. For the Screen2Green project, scope control is managed collaboratively by the project team, with guidance from supervisors.
  
  
-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.+The WBS serves as the primary reference for scope control. Each element in the WBS defines specific tasks and deliverables, and the team uses this structure to ensure that only the planned work is carried out. By following the WBS, the team maintains focus on completing the required components of the prototype and associated documentation within the given timeframe.
  
  
-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.+As the project progresses, new ideas and potential improvements naturally emerge, particularly due to the interdisciplinary nature of Screen2Green. These may include additional sensors, expanded application features, or alternative approaches to plant monitoring. However, any proposed changes to the scope are carefully evaluated before being implemented. Suggestions can be raised by any team member and are discussed within the group, taking into account technical feasibility, available time, and alignment with the core objectives of the project.
  
  
-The main project milestones are presented in Table {{ref>project_milestones}}.+Supervisors may also provide input on potential changes during regular meetings. If a proposed change is considered beneficial, the team assesses its impact on the overall project, including workload, timeline, and system complexity. Changes are only accepted if they support the main goal of linking screen-time behaviour to plant care and do not compromise the completion of essential deliverables.
  
 +
 +Only features that directly support the core concept are included, while additional ideas are documented as potential future improvements. This approach helps prevent scope creep and ensures that the project remains focused, realistic, and achievable within the available resources.
 +
 +
 +Scope verification is carried out continuously through testing and evaluation of the system components. The team assesses whether the prototype meets the defined requirements and objectives, including successful integration of hardware and software and the functionality of the feedback mechanism. Feedback from supervisors and testing results are used to confirm that the project remains aligned with the defined scope.
 +
 +==== 3.2 Time ====
 +
 +/*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.
 +
 +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.
 +
 +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}}.
  
 <WRAP center round box 60%> <WRAP center round box 60%>
Line 74: Line 98:
 | 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 112: Line 132:
 |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 [(quality_metrics_template)]. 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 application. 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}}. These metrics are used to evaluate whether the prototype meets the minimum requirements for functionality and performance within the scope of the project.
- +
- +
-In order to assess quality, the team defined the following general metrics:+
  
 <table quality_metrics> <table quality_metrics>
 <caption>Quality metrics for Screen2Green development</caption> <caption>Quality metrics for Screen2Green development</caption>
-^ Quality aspect ^ Target/threshold ^ Verification method ^ +^ Metric ^ Description ^ Threshold ^ Review method ^ 
-|Funtional operation|Core functions operate as intended|Funtional testing| +|Functional operation|The system must correctly link screen-time data to plant watering behaviour|Screen-time input triggers corresponding watering response during testing|Functional system testing| 
-|System reliability|No critical malfunction during controlled testing|Repeated tests and observation| +|System integration|Hardware and software components must communicate correctly|App, microcontroller, and watering system interact without failure|Integration testing| 
-|Water safety|No significant leakage during operation|Prototype testing| +|System reliability|The system should operate consistently during repeated use|No critical malfunction during multiple test runs|Repeated testing| 
-|Usability|Users can understand basic interaction and feedback|User testing/evaluation| +|Water safety|The system must safely handle water without damaging electronics|No visible leakage and no contact between water and electrical components|Prototype testing| 
-|Documentation quality|Chapters complete, coherent, and aligned with requirements|Internal review and supervisor feedback|+|Usability (SUS)|The app should be understandable and easy to use|Average SUS score ≥ 68 (standard usability threshold) [(hyzy2022sus_benchmarking)]|User testing (SUS questionnaire)| 
 +|API performance|Backend should respond efficiently to requests|Average response time below 1000 ms and preferably below 300 ms [(api_response_time_standards)]|Postman performance testing| 
 +|API load handling|System should handle increasing request load|Response time remains stable under increasing load (1, 10, 100 requests)|Load testing (Postman / JMeter)| 
 +|API reliability|System should handle requests with minimum failure|Error rate = 0.1-1% during testing [(api_error_rate_analysis)]|Postman testing| 
 +|Documentation quality|Project documentation must meet academic standards|All required sections completed 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 === 
 + 
 +Key stakeholders represent the individuals or groups who have significant influence over the project or are directly affected by its implementation. 
 + 
 +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. 
 + 
 +  * 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. 
 + 
 +  * 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. 
 + 
 +  * 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.*/ /*Document how your team will manage communications, describing communication channels, meetings, etc.*/
  
 +Communication plays a central role in coordinating the project and maintaining progress across technical development, documentation, and planning activities [(communications_management_plan_template)]. Since the team works across multiple disciplines and perspectives, a structured communication strategy is necessary to reduce misunderstandings and support effective collaboration.
  
-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.+=== 3.6.1 Communication approach and tools ===
  
 +Communication in the Screen2Green project is managed through a combination of structured meetings and digital tools. The approach focuses on ensuring transparency, regular updates, and clear task ownership across the team. Both formal communication, such as scheduled meetings, and informal communication, such as quick discussions and messaging, are used to support coordination and decision-making throughout the project.
  
-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. 
  
 +The Screen2Green project uses several communication methods and digital tools to support coordination within the team. Regular Scrum meetings are used to discuss progress, coordinate tasks, and identify possible blockers. During these meetings, team members share what they have worked on, what they plan to work on next, and whether they need support from others.
  
-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.+Jira is used as the main project management tool for planning and tracking tasks. It helps the team organize sprint work, assign responsibilities, and follow the status of ongoing activities. Google Calendar is used to keep track of meetings, deadlines, and important project milestones. Microsoft Teams is used as a shared workspace for communication, file sharing, articles, and project 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.+=== 3.6.2 Communication frequency and flow === 
 + 
 +Communication occurs at different frequencies depending on the purpose. Scrum meetings are held regularly, and from sprint 3 onward, they take place three times per week (Friday, Monday, and Wednesday). During these meetings, each team member reports on completed tasks, upcoming work, and any challenges encountered. 
 + 
 +In addition to formal meetings, communication takes place continuously through WhatsApp, allowing team members to coordinate work, ask questions, and share updates in real time. This combination of structured and continuous communication helps ensure that information flows effectively within the team. 
 + 
 + 
 +=== 3.6.3 Communication challenges and improvements === 
 + 
 +Despite these structures, communication within the team is initially challenging. Differences in working styles, expectations, and levels of detail sometimes lead to inefficiencies, delayed responses, and incomplete coordination. In some cases, tasks are completed without being updated in Jira, which reduces transparency and makes planning more difficult. 
 + 
 + 
 +To improve this situation, the team places more emphasis on structured meetings, clearer task ownership, and more consistent use of Jira for tracking progress. Increasing the frequency of Scrum meetings also contributes to better alignment and faster identification of issues.
  
  
Line 177: Line 267:
  
  
-==== 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. Risk management is therefore essential to ensure that potential issues are identified early and handled in a structured and proactive manner throughout the project [(risk_management_plan_template)].
  
-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. 
  
 +=== 3.7.1 Risk management approach ===
  
-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.+Risk management in the Screen2Green project is carried out continuously throughout the project lifecycle. The team identifies, evaluates, and manages risks collaboratively, with input from supervisors during regular meetings.
  
  
-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.+Risks are assessed based on their probability of occurrence and potential impact on the project. This allows the team to prioritize critical risks and focus on mitigation strategies that support the successful completion of the prototype. The WBS and project plan are used as references to identify risk areas related to specific tasks and deliverables.
  
 +=== 3.7.2 Risk identification ===
  
-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.+Several key risks have been identified during 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. 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. 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. 
  
 +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. Organizational risks such as miscommunication and uneven workload distribution may also affect progress.
  
-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. 
  
 +=== 3.7.3 Risk assessment and prioritization ===
  
-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 evaluated based on their probability and impact, as summarized in Table {{ref>project_risks}}. A risk matrix is used to classify risks into low, medium, and high categories (see Figure {{ref>risk_matrix}}).
  
  
-The identified risks are summarized in Table {{ref>project_risks}}. 
  
 <table project_risks> <table project_risks>
Line 216: Line 309:
  
  
-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> 
 +<caption>Risk matrix</caption> 
 +{{ :report:risk_matrix.png?600 |}} 
 +</table>
  
  
-<WRAP center round box 60%> +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 are prioritized and require continuous attention throughout the project.
-<figure risk_matrix> +
-{{ :report:risk_matrix.png?600 |}} +
-<caption>Risk matrix</caption> +
-</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.+Medium-level risks, such as sensor inaccuracies, water leakage, and plant response, are managed through testing and design adjustments. Lower-level risks, including communication issues and uneven workload distribution, are addressed through team coordination and regular meetings.
  
  
-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.+=== 3.7.4 Risk monitoring and mitigation === 
 + 
 +Risk monitoring is carried out continuously throughout the project. The team regularly reviews identified risks during meetings and evaluates whether their probability or impact has changed. This allows for early detection of new risks or changes in existing ones. 
 + 
 + 
 +Mitigation strategies are implemented to reduce the likelihood or impact of each risk. For example, technical risks are addressed through modular system design and incremental testing, allowing issues to be identified early. Risks related to system reliability, such as water leakage or sensor inaccuracies, are managed through controlled testing and careful design decisions. 
 + 
 + 
 +To reduce the risk of project delays, the team uses sprint planning, task prioritization, and regular progress reviews. Organizational risks, such as miscommunication or uneven workload distribution, are mitigated through clear task allocation and continuous collaboration within the team. 
 + 
 + 
 +Only solutions that support the core concept of linking screen-time behaviour to plant care are prioritized. This ensures that risk mitigation efforts remain aligned with the main objectives of the project and prevents unnecessary complexity. 
 + 
 +==== 3.8 Procurement ====
  
-==== Procurement ==== 
-== Introduction ==  
 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 258: Line 367:
  
 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 271: Line 381:
 <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 292: Line 402:
 </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 304: Line 416:
 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 341: Line 505:
 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 360: Line 525:
     * 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 385: Line 551:
 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 400: Line 567:
   * 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.1775990333.txt.gz
  • Last modified: 2026/04/12 11:38
  • by team1