Meeting 04.04.2024 - Scrum Processes
Participants
- Markus
- Andrei
- Yvonne
Questions
The main questions to answer:
- How can we improve the way we create and work on issues?
- How can we improve the way we deal with reviews of PRs?
Takeaways:
- Every 3 weeks, include a 30min retro in the meeting by Andrei
- After releases, we have small demo so team is up to date with what's new.
- Explore how GitLab can help us structure issues around Use Cases/Features
- Try to have only issues that have an estimation of one week (can be done in the scope of one "sprint") - If they are too big, they should be broken down into sub-tasks
- Reviews should be more structured - what type of review is it? (what should be checked - code/documentation/testing etc.), what issue is it relating to
- Submissions README.md as source of "expertise" - reviewers that match the expertise needed
- Look into having separate "Master" and "Dev" Branches
Meeting Notes
General points brought up and short discussion on each:
- Timeboxes from Scrum
- Don't fully make sense in the scope of the project, sprints can't be longer than 1 week if there are no other regular touchpoints (e.g Daily Scrum)
- Retro/Review
- Might be interesting to try and integrate those concepts in our current meeting flow
- From Use Cases to Issues to Pull Requests
- We need a better structure, like the concept of "Epic"s or "Feature"s to categorize the issues. This might be better supported by moving to GitLab
- What kind of info should an issue contain? From Use Cases to everything needed for implementation - currently, details might be missing that we only become aware of later
- PRs and Reviews
- Important to have a clear linking between the PR and the task it relates to, clear indication of what the Scope of the PR is, try not to combine multiple issues into one PR
- Who should review? - we can use information from the submissions readme and have some rules of assigning reviews based on expertise - who can most help you review the part of the application you changed
- PRs should not stay open for too long, to keep the Branches more stable and avoid conflicts
- We should clean the older/"orphaned" PRs
- Task Estimation
- In the past, explicit estimation did not work well for the structure of the project. Try to stick to Issue size that is managable in the "sprint" time of one week