Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update sprint review presentation guidelines #512

Merged
merged 4 commits into from
Nov 21, 2024
Merged

Update sprint review presentation guidelines #512

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
c76df15
Update the sprint review presentation guideline
ll7 Nov 19, 2024
9a693eb
Update sprint review presentation guidelines for clarity and accuracy
ll7 Nov 19, 2024
f2ae9e8
Refine sprint review presentation guidelines for clarity and conciseness
ll7 Nov 21, 2024
34bcea9
Merge branch 'main' into 452-Update-the-sprint-review-presentation-gu…
ll7 Nov 21, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion doc/dev_talks/paf24/sprint_review_meeting_guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 will be updated. in [#452](https://github.com/una-auxme/paf/issues/452).
- [sprint_review_presentation.md](../../development/sprint_review_presentation.md) will be updated accordingly.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Fix grammatical error and update incorrect document path

The document path in the markdown file is incorrect. Please apply these changes:

-The sprint review presentation guideline will be updated. in [#452](https://github.com/una-auxme/paf/issues/452).
+The sprint review presentation guideline will be updated in [#452](https://github.com/una-auxme/paf/issues/452).
-[sprint_review_presentation.md](../../development/sprint_review_presentation.md)
+[sprint_review_presentation.md](../../../doc/development/sprint_review_presentation.md)
  • Fixed the grammatical error by removing the unnecessary period
  • Corrected the relative path to the presentation document which is located at doc/development/sprint_review_presentation.md
🔗 Analysis chain

Fix grammatical error in the update note.

There's a grammatical error in the sentence structure.

Apply this diff to fix the punctuation:

-The sprint review presentation guideline will be updated. in [#452](https://github.com/una-auxme/paf/issues/452).
+The sprint review presentation guideline will be updated in [#452](https://github.com/una-auxme/paf/issues/452).

Let's verify the referenced documents exist:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the existence of referenced documents and their paths

# Check if the referenced presentation document exists
fd -t f "sprint_review_presentation.md" development/

# Check if the summary template exists (referenced in the document)
fd -t f "sprint_summary_template.md" doc/dev_talks/paf24/

Length of output: 257

Script:

#!/bin/bash
# Let's verify the correct path for the presentation document
fd -t f "sprint_review_presentation.md"

# Also check if there might be a different base directory
ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//  /g' -e 's/^/  /'

Length of output: 1795


## 3. Sprint Review Schedule

Expand Down
82 changes: 28 additions & 54 deletions doc/development/sprint_review_presentation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,76 +1,50 @@
# 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 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 live demo or walkthrough of the feature or bug fix that the PR addresses.
- **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/>

Expand Down
Loading