Core Platform - Retrospective / Action Plan

Core Platform Retro board: https://easyretro.io/publicboard/RafsurmL5WV1R3DtSGoLA8qCC5q1/ce67b86f-c511-47e4-a812-a95ea665af73

You can add cards in advance and we will review on the next retro

Action Plan	Notes
November Retro
Engage operators, dev ops, security team to conversation and get feedback from them to decide which improvements can be done. Jakub Skoczen / Dilshod_Khusanov organize this conversation
Think about old modules refactoring - Adam Dickmeiss Mikhail Fokanov Julian Ladisch Steve Ellis
Come up with long term objectives for the next release and later discuss on TL. Julian can provide and input. Jakub Skoczen will create document to provide Objectives
Review and plan increasing coverage of CT modules. Can be done during code refactoring - Adam Dickmeiss Mikhail Fokanov Julian Ladisch Steve Ellis
September Retro
Update User story for Improving documentation for working with scratch env - Steve Ellis	Done
Create User Story for Creating jenkins job to allow for platform complete deployment to scratch - Steve Ellis	Ongoing. I didn't create a user story but the dev ops people are actively working on improving the Jenkins pipelines to build the scratch environments.
Add this part to the US about creating jenkins job for platform complete Consider creating a rancher/k8s reference environment for platform complete - Steve Ellis
Create User Story "Improve folio-helm repo with better container defaults for ram and cpu" - Steve Ellis	I'm reaching out to dev ops people for recommendations on how to approach this.
document experience of running Karate tests against rancher env and share/demo this for other dev teams - Steve Ellis	Done
July Retro
Try to include to iteration USs based on planned capacity - Adam Dickmeiss Hongwei Ji Mikhail Fokanov Julian Ladisch Steve Ellis Hanna Hulevich Jakub Skoczen	keep doing this
Emphasize one more time to management and stakeholders that CP team has not enough resources to accomplish tasks. OL took a lot of time but still not done. We can't commit to anything with this set up - Jakub Skoczen
Use release filed instead of label - Adam Dickmeiss Hongwei Ji Mikhail Fokanov Julian Ladisch Steve Ellis Hanna Hulevich Jakub Skoczen	keep doing
June Retro
Add vacations to the core platform calendar in advance (before sprint starts) - Adam Dickmeiss Hongwei Ji Mikhail Fokanov Julian Ladisch Steve Ellis Hanna Hulevich Jakub Skoczen	keep doing
Create clone and close clone in the end of sprint. and keep original ticket open - Adam Dickmeiss Hongwei Ji Mikhail Fokanov Julian Ladisch Steve Ellis Hanna Hulevich Jakub Skoczen	keep doing
Start using UXPROD for big features (like OL) - Jakub Skoczen	keep doing
April Retro
Hanna Hulevich Email to Anton and ask about progress with test env
Jakub SkoczenTalk to devOps about creating snapshot env for CP team only and grand CP with all required perms	we did not need this for R2. wait for Abdu to create env (Hanna check with Abdu)
Hanna Hulevich proceed dedicating time for spike results discussion	keep doing
Adam Dickmeiss Julian Ladisch Craig McNally Hongwei Ji Mikhail Fokanov Hanna Hulevich Jakub Skoczen Set deadline for providing spike results feedback
Adam Dickmeiss Julian Ladisch Craig McNally Hongwei Ji Mikhail Fokanov Hanna Hulevich Jakub SkoczenTry to deliver as much as we can to R2 starting from the most important items but commit to nothing	keep doing
Jakub Skoczen Keep backlog sorted by priorities	keep doing
February Retrospective
Julian Ladisch , Adam Dickmeiss , Hongwei Ji , Jakub Skoczen Mikhail Fokanov Provide feedback for FOLIO-3029 - Getting issue details... STATUS . We need to collect all requirements for this environment to make sure all possible tests are covered
Hanna Hulevich Communicate to Anton when requirements are ready
Adam Dickmeiss Julian Ladisch Craig McNally Hongwei Ji Mikhail Fokanov Include investigation efforts into the User Story estimates	keep doing
Adam Dickmeiss Julian Ladisch Craig McNally Hongwei Ji Mikhail Fokanov Do more testing before sending messages to other teams	keep doing
Adam Dickmeiss Julian Ladisch Craig McNally Hongwei Ji Mikhail Fokanov Hanna Hulevich Jakub Skoczen Mention team member in slack if you are waiting response	keep doing
2020
Retro board link - Sprint 56: https://funretro.io/publicboard/DEeWRRqubCaQXm7WfKdjSZfC3wK2/-LYC7zUogkzCb1L-kjlT Retro board link - Sprint 57: https://funretro.io/publicboard/DEeWRRqubCaQXm7WfKdjSZfC3wK2/-LZEjgi7I9h-MaMVbKvy Retro board link - Sprint 59: https://funretro.io/publicboard/uhS7lurEs9WACO0ZcntIKkeLqUq1/-La1-uNe83Y7e7s0DpVp?pageId=14459935 Retro board link - Sprint 64: https://funretro.io/publicboard/uhS7lurEs9WACO0ZcntIKkeLqUq1/-LeqW9y38TmHZ22UOOaj Retro board link - Sprint 69: https://funretro.io/publicboard/uhS7lurEs9WACO0ZcntIKkeLqUq1/de9a18bd-dfc0-406d-95d8-8db4040b6106
Add detailed acceptance criteria before story estimation
Keep meetings as short as possible
Groom stories before sprint starts
Organize grooming backlog in streams (Devops/Backend/Common)	Not effective
Form working groups about particular tickets outside of stand-ups
Verify that issue is not blocked when including in the sprint
Try not to add stories in the middle of the sprint
Reserve some bandwidth to operational issues
Become familiar with the ticket before grooming.	Effective
Conduct two grooming sessions for Devs and DevOps.	Not effective
Limit discussion for 1 ticket to 10 minutes during the grooming.	Check with the team if we are going to spend more time on it after 10 minutes
If we groom a story and there is not enough description - we move it into the DRAFT status and don't pick up into the sprint.
On standup inform the team (+ creator of the story) when more description is needed.
All big features should start with an investigation. Then it should be discussed with a group of engineers. The feature should be 'drived' be someone. We should have a special event in order to discuss a big solution. Raise a request for such an event during the daily scrum.
Set up times to review spikes / new infrastructure. Either synchronous or start PRs early for review.
Each spike should have some outcome: a document, PoC and it should be reviewed by the team.