| Panel | ||||
|---|---|---|---|---|
| ||||
What did we do well? |
- Communication and atmosphere between team members was great and good. In particular
- Questions, (technical) discussions and the translation of domain knowledge to software knowledge
- Continuous checking of the (algorithm) implementations
- Dynamic adjustments of the issue implementations
- Expectations were adjusted accordingly based on the progress during the "sprint"
- The end result that was achieved
| Panel | ||||
|---|---|---|---|---|
| ||||
What should we have done better? |
Issue description (also remainder of the last retrospective):
The issue descriptions are unclear, incomplete
In order to improve this:
Action points:
- Screenshots and other visual supports should be added to the issues to support the issue description
- More effort should be put in the mapping of "domain terminology" and the "software terminology"
- Expected behaviour / functionality should be described in the issue prior before the sprint starts. The functionality is not necessarily set in stone: this can be updated when there are unforeseen circumstances while implementing. In this situation, discuss it with the P/O and update the issue description accordingly to make the implicit knowledge explicit
Refinement meetings will be held.
Refinement
Action points:
- Refinement meeting should be held prior to the start of the sprint. Each member should read the descriptions to determine whether the issue is clear
- Instead of basing the estimation on the P/O and the Scrum Master, the entire team will be involved in the estimation during the refinement meeting by means of sprint poker
- P/O and the Scrum Master will sit and discuss together which
Critical/disrupting events that hamper the development progress:
The instability of the build server should have been picked up asap
Action points:
- These should receive the highest priority and must be solved as soon as possible
Maintainability:
Features are being implemented, but there's no attention to any maintenance, clean up or refactoring of components
Action points:
- There will be sprints planned purely related to the maintenance of components, preferably prior to sprints that are focused on implementing new features
- The P/O is responsible for determining what kind of functionality, developers can then determine which areas should be focused on and be refactored.
- In case the P/O has no vision on new functionality, the developers can determine which areas should be focused on that will result in the largest gain
Branching
The intention is that the BOI branch (version 2.X) replaces the version on the trunk (version 1.X)There is currently a risk that the two branches cannot be merged together the longer the development continues
Action points:
- The BOI branch will be merged during the follow-up sprint of the XBeach Erosion Model
| Panel | ||||
|---|---|---|---|---|
| ||||
| What are remaining action points of the last retrospective? |
Release procedure:
The release procedure is currently unlogical and should be improved
Action points:
The procedure is clear and formalised, but could use the following improvements:
- Add a functional checklist on what needs to be checked when a new release is made
- Provide a template on the wiki on what needs to be done when making a release
- Perhaps we can automate some steps when releasing MorphAn
Testers planning
The planning with the tester was suboptimal
As MorphAn cannot always supply the tester with sufficient work on planned days, some flexibility is sometimes required from the testers and it is advisable for them to prepare a backup work package when necessary:
Action points:
- Request the tester to prepare a backup work package at the start of the sprint
Test data:
Issue data is not always available or unclear where it is located
Action points:
- Each issue should have preferably an attachment containing the test data. If this is not possible due to file size limits:
- The issue should contain a file path of where the data can be found; OR
- The issue should contain a file path of where generic data can be found AND contain steps how to create the desired state of the application.
Actions
- Plan meeting together with P/O to discuss the technical possibilities/implementation and the desired functionality
- Plan a refinement meeting at the start of a sprint with every participant + apply planningspoker for estimations