Merge pull request #512 from una-auxme/452-Update-the-sprint-review-p…

…resentation-guideline

Update sprint review presentation guidelines

doc/dev_talks/paf24/sprint_review_meeting_guidelines.md

@@ -43,7 +43,8 @@
   - Example: A team of three has a total of 15 minutes and may allocate time as they see fit.
   - A unified grade will be given unless individual assessment is warranted.
 - Timeboxing will be strictly enforced: only content shared within the allotted time will be evaluated. Presentations will be stopped at the time limit.
-- TODO The sprint review presentation guideline will be updated.
+- The sprint review presentation guideline was updated in [#452](https://github.com/una-auxme/paf/issues/452).
+  - The [sprint_review_presentation.md](../../development/sprint_review_presentation.md) is updated.
 
 ## 3. Sprint Review Schedule
 

doc/development/sprint_review_presentation.md

@@ -1,76 +1,51 @@
 # Sprint Review Presentation
 
-**Summary:** Guidelines for creating effective presentations for Sprint Reviews in the PAF project.
+**Summary:** Guidelines for creating effective presentations for the Sprint Reviews in the PAF project.
 
-- [1. General Sprint Progress Overview Presentation](#1-general-sprint-progress-overview-presentation)
-- [2. Individual Pull Request (PR) Presentations](#2-individual-pull-request-pr-presentations)
-- [3. Presentation Style](#3-presentation-style)
+- [1. Group Presentations](#1-group-presentations)
+- [2. Presentation Style](#2-presentation-style)
 
 Creating a good presentation for a **Sprint Review** in PAF is important for communicating the team's achievements, identifying challenges, and planning for future work.
 
-To present the sprint progress effectively, especially when dealing with complex software projects, it can be beneficial to split the presentations into two distinct parts:
+## 1. Group Presentations
 
-1. **General Sprint Progress Overview**: This focuses on the big-picture updates, team-wide accomplishments, challenges, and next steps.
-2. **Individual Pull Request (PR) Presentations**: These dive into the details of specific features or changes made during the sprint.
+These are technical presentations meant to present project progress from the sprint.
+Not every PR has to be presented, but **each students contribution should be presented**.
 
-## 1. General Sprint Progress Overview Presentation
+**Structure of Presentation**:
 
-This presentation is designed for a broader audience and focuses on the overall progress made during the sprint. It highlights major milestones, project status, and challenges, without diving into technical implementation details.
-There should be one general overview presentation per sprint, typically delivered a new student who has not presented the general overview before.
-
-**Structure of the General Overview**:
-
-- **Title Slide**: Sprint number, project name, team, and sprint dates.
-- **Agenda**: Outline the structure of the presentation.
-  - *See below*
-- **Sprint Goals**: Briefly describe the objectives of the sprint and how they fit into the overall project roadmap.
-- **Completed Work**: Provide an overview of features that were completed. This section should focus on **overall vehicle improvement** rather than technical details.
-  - Optionally include a **demo** of key features.
-  - **Before-and-after visuals** of new functionality if applicable.
-- **In-progress Work**: Mention features or tasks that were started but not completed, along with explanations of why they weren’t finished.
-- **Challenges & Blockers**: Present the key blockers and how they were addressed or escalated. If some remain unresolved, suggest plans for mitigation.
-- **Sprint Metrics**: Include relevant metrics:
-  - Any improvements in testing or driving score.
-- **Next Steps**: Outline the focus areas for the next sprint, upcoming deadlines, and potential risks.
-
-**Duration**: 5-20 minutes, depending on the complexity of the sprint.
-
-## 2. Individual Pull Request (PR) Presentations
-
-These are more focused, technical presentations meant to review individual pull requests (PRs) from the sprint. They are aimed at the development team and technical stakeholders, providing detailed insight into the code changes, implementation logic, and technical considerations of each PR.
-Not every PR has to be presented, but **every student should be able to highlight their contributions**.
-
-**Structure of the PR Presentation**:
-
-- **Title Slide**: Pull request title, associated issue number(s), and contributor(s).
+- **Title Slide**: Area of contribution, PR numbers, and contributor(s).
 - **Agenda**:
-  - *See below*
-- **PR Overview**: Start with the problem or issue the PR addresses.
-  - Describe the goal of the changes (e.g., adding a feature, fixing a bug, refactoring code).
-- **Key Accomplishments**: Go over the technical changes made in the PR.
-  - **Code snippets**: Highlight important parts of the code that were changed or added.
-  - **Design patterns or architectural choices**: Explain any significant technical decisions.
-- **Technical Challenges and Solutions**: Discuss any technical difficulties encountered while implementing the PR.
-  - Mention how challenges were overcome and what alternatives were considered.
-- **Code Review Outcomes**: Summarize any feedback from peer reviews.
-  - Highlight any requested changes and how they were addressed.
-  - Point out best practices followed or any areas for future improvement.
-- **Testing and Validation**: Show how the changes were tested.
+  - Clearly outline what will be covered.
+- **Overview**:
+  - Start by describing the problem or feature request being addressed.
+  - Explain the goal of the changes.
+- **Key Accomplishments**:
+  - Summarize the technical changes made during the sprint.
+  - Highlight key features implemented or problems solved.
+  - Design Patterns/Architectural Choices: Explain significant technical decisions.
+- **Technical Challenges and Solutions**:
+  - Discuss challenges encountered and how they were resolved.
+  - Outline alternative approaches considered, if any.
+- **Code Review Outcomes**:
+  - Summarize feedback received during peer reviews.
+  - Highlight requested changes and how they were addressed.
+  - Mention best practices followed and areas for improvement.
+- **Testing and Validation**: Explain how the changes were tested.
   - **Automated tests**: Unit, integration, or end-to-end tests that were added or updated.
   - **Manual tests**: If manual validation was done, explain the scenarios tested.
-- **Demo (if applicable)**: Provide a quick live demo or walkthrough of the feature or bug fix that the PR addresses.
-- **Next Steps**: If the PR impacts other work or needs further iterations, describe those next steps.
+- **Demo**: Provide a quick demo or walkthrough of the feature or bug fix that the PR addresses.
+  - Prepare screenshots or recordings.
+- **Next Steps**: If the changes impacts other work or needs further iterations, describe those next steps.
 
-**Duration**: 5-10 minutes per Pull-Request.
+**Duration**: **5 minutes** per person.
 
-## 3. Presentation Style
+## 2. Presentation Style
 
 - **Focus on outcomes**: Highlight the progress made and how it impacts the overall project goals.
 - **Use visuals and charts**: Use screenshots, graphs, and videos to illustrate progress.
-- **Interactive**: Ask for feedback, highlight areas that require input or decisions.
 - **Keep it high-level**: Avoid too much technical jargon.
 - **Stay concise**: Respect everyone’s time and keep the presentation focused on what matters most.
-- **Collaborate**: Collaborate with the team to ensure all aspects of the sprint are covered.
 - **Consistent Slide Design**: Use a consistent slide design (fonts, colors, layout) to improve readability.
   - Templates for AuxMe-Presentations: <https://mediastore.rz.uni-augsburg.de/get/EJ74okFZE2/>