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.

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 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 project perspective, the scope includes all activities necessary to research, design, develop, and document the prototype, as shown in Figure 1, 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 WBS, which organizes the project into manageable components [1].

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

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.

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.

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 [2]. For the Screen2Green project, scope control is managed collaboratively by the project team, with guidance from supervisors.

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.

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.

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.

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

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.

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.

A preliminary estimate of the prototype cost is presented in Table 2 .

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.

Quality management in this project focuses on ensuring that the prototype, documentation, and associated deliverables meet the expected technical and academic standards [3]. 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.

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.

In order to assess quality, the team defined the general metrics listed in Table 3. These metrics are used to evaluate whether the prototype meets the minimum requirements for functionality and performance within the scope of the project.

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.

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.

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.

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.

The project team utilizes the following power and interest levels to determine the most effective management strategy for each group.

Figure 2 shows the power/interest matrix with all the stakeholders.

The identified risks are summarized in Table 4.

Communication plays a central role in coordinating the project and maintaining progress across technical development, documentation, and planning activities [7]. Since the team works across multiple disciplines and perspectives, a structured communication strategy is necessary to reduce misunderstandings and support effective collaboration.

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.

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

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.

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.

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.

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 [8].

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.

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.

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.

The identified risks are evaluated based on their probability and impact, as summarized in Table 5. A risk matrix is used to classify risks into low, medium, and high categories (see Figure 6).

Table 6: Risk matrix

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.

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.

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.

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.

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.

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.

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. 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.
  • the opposite is also impossible.
• Subtasks are separate entities from tasks.
• Subtasks aren't visible on the sprint board.
• Themes don't exist.

To keep a clean and understandable sprint log, the team decided to use features and their subtasks for tasks, which are divided under epics, which are finally divided under labels. Labels replace themes in this case.

The team decided to prioritize tasks and define sprint themes based on 3 topics. These are deliverables, tasks/features with multiple dependencies and lastly, internally decided research topics. Apart from that, each sprint functions as an increment on the prior's app and microcontroller development, as well as design.

Figure 3 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.

Table 7 contains the global sprint plan. Every sprint is defined by their sprint period, a theme/main focus, amount of deliverables, status and percentage of finished stories & tasks.

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

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.

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

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.

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.

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.

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.

Half of the tasks in the global backlog were designated to the deliverables, while the other half consisted of plant pot related tasks. The sprint backlog consisted of app related tasks, 3D model related tasks and report related tasks.

The backlog has very few tasks left with the only ones being deliverable related. The sprint backlog now has tasks about the leaflet, the packaging solution, the application and new research topics. This sprint's weight is notably small compared to previous sprints.

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.

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

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

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.

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.

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.

The team felt like this sprint was more relaxed compared to others. The weight was smaller, the team members finished their tasks early on and the tasks were divided more fairly this time. The only tasks that were unfinished were those blocked due to problems with the 3D model and minor application related tasks.

The team evaluated this sprint as an improvement and wants to keep this energy and weight distribution over the final few sprints.

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.

After the team gained a better view on the project and what the teachers expect, it became easier to focus on design. The physical and ethical design were of top priority, so all research done in this week was based on these 2 topics. Apart from that, there was heavy research on growing herbs and more specifically, basil. Lastly, the team collected some foundational questions to ask before diving further into this project.

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

What went well:

• Deliverables were finished in time and there was room for enough evaluation.

What didn't go well:

• Miscommunication lead to a missing agenda.

What should the team:

• Keep doing:
  • /
• Start doing:
  • Define assignees for tasks more early in the sprint.
  • Define tasks for smaller topics such as agenda creation.
• Stop doing:
  • Procrastinate task assignment.

What went well:

• Communication improved, the team engaged with each other more frequently upon finished tasks.
• The team started with a great amount of tasks and finished around 90% of them.
• The team set a stronger baseline and gained more certainty in their project scope.

What went wrong:

• Although there was more communication, this often came later than desired.
• The didn’t fix the failed deliverables in time.
• Task division happened in an unbalanced manner and tasks had no weight to them.

What the team should:

• Keep doing:
  • Improve their communication.
  • Update each other on finished tasks by sending messages.
• Start doing:
  • Reply to each other's messages/requests.
  • Review the Wiki more frequently.
  • Start using task weights and priority.
  • Improve importance ordering of tasks and features.
• Stop doing:
  • Research with insufficient efficiency and write non-qualitative reports.

Summary: 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.

What went well:

• Improvement in communication.
• Improvement in engagement.

What didn't go well:

• Small number of tasks were completed.

What should the team:

• Keep doing:
  • Update each other on task completion in WhatsApp.
• Start doing:
  • Put more time into planning the next sprint and focus on factors such as sprint length, holidays and unavailabilities.
  • Overestimate tasks and sprints instead of underestimating them.
• Stop doing:
  • /

There was no retrospective this sprint due to a similar sprint backlog and project backlog.

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.

The team thought that just like in last sprint the task division was unfair and that people underestimated the weight of their tasks.

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.