Retrospective
What did we do well?
- Communication between team members was great and good, despite working form home
- The description of the issues improved comapred to the last sprint. Issues were clearly described and questions about the issues were clearly explained or answered
- (Kickoff) meeting with the stakeholders was very motivating
- Demo data that was made available for this sprint sped up the development process
- There's room to improve existing architecture of MorphAn
- The result of the sprint was above satisfactory: more than promised was delivered and sprint velocity was high
What should we have done better?
The main point of discussion during the retrospective was that:
The planning with the tester was suboptimal
In order to improve this:
Action points:
- Introduce a buffer when there's a release. Don't release on the last day, but allow some space to introduce improvements if necessary
- Testing on the VM slows down the testing procedure. It will be the task of the P/O and the developers to indicate whether an issue has an impact on the performance (e,g, algorithmic complexity and/or memory constraints)
- Instead of testing 1 full day by a tester, spread it over 2 half days
- In the week of the release, introduce half a day extra to allow testing after improvements were made
Release procedure:
The release procedure is currently unlogical and should be improved
Action points:
- As an immediate action point: the release procedure will be documented to formalize the procedure
- The following procedures are immediately applicable for this sprint:
- Any hotfixes that are relevant for the 1.9.0 release will be committed on the release branch and merged back to the trunk
- The trunk will immediately upgrade the minor version number after a release branch is made
Test environment:
The testing environment is insuffcient in reproducing all issues on the board
Action points:
- The following resolution is to be used when testing the issues: 1920 x 1080, 125% scaling. Preferably tested on a laptop screen
- A single device is taken as "truth." If issues are not reproducible on that machine, the issue is probably not reproducible.
Actions
- The release procedure is formalised and documented. Improved where necessary See: Release procedures
- Planning will take buffers into account to allow improvements to be made after testing (and retest the improvements)
