Concorde - Retrospective / Action Plan

Concorde retrospective board

Ongoing improvements

Ongoing improvements

Issues that are reported during release should be treated as high priority. In case of P1 and P2 issues instant refocus is required. @Oleksiy_Lemeshko and @Viktor Soroka to coordinate with the team
Responsible dev should involve other team members if needed
Updates on issue resolution progress should be provided when there are such but not delayed till daily stand-up

From S99 retro:

If you face an issue that blocks the story that is currently in your hands - please do log corresponding ticket and link both / suggest to take into a sprint / raise in your daily update / etc.

The discription of the PR should contain the details of bugfix OR please do raise it during stand-up update in slack or zoom

It is important to meet agreed deadlines. If you see that you're not going to make it - please speak up the sooner the better, providing the reasoni

Bugfix releases should be done by the people with no such previous experience. Applicable for UI and BE

From S101 retro:

P1/P2 issues pattern:
1. Check on your local envs / Request logs from the environment the issue occured on
3. Make one's efforts visible to the team by commenting the Jira item and keeping everyone updated in slack

Next sprint improvement action items

Next sprint improvement action items
4
Be more careful when estimating infra stories (RMB, etc)

@Oleksiy_Lemeshko to update templates in mod-data-export and mod-oai-pmh projects @Oleksiy_Lemeshko to check with other teams how they release bugfixes in parallel with other tickets Release retro: Cross-team communication to be improved in terms of notifying PO, SM, TL about items being added to backlog of another team

@Oleksiy_Lemeshko to update templates in mod-data-export and mod-oai-pmh projects @Illia Daliek To check with TarasS the reason of data import module exclusion from default vagrant boxes setup @Oleksiy_Lemeshko to check with other teams how they release bugfixes in parallel with other tickets @Igor Gorchakov to setup and lead brainstorm session re the same Release retro: Cross team communication to be improved in terms of notifying PO, SM, TL about items being added to backlog of another team

Start analyse the impact of human related risks (sickleaves, unplanned vacations, etc) on any sprint @IlliaD To check with TarasS the reason of data import module exclusion from default vagrant boxes setup Diligent with migration scripts: Schema comparison (to be raised during couple of forthcomming retros)




Team agreed and @Oleksiy_Lemeshko to document the team approach to POCs. POC estimation approach (not Spikes) Provide verification steps for the completed backend stories. Kruthi's comments are gold-standard Verify backend stories on the scratch environment first and then on the snapshot once available there Be time conscientious when it comes to PRs Oleksiy to monitor In Code Review column Provide planned capacity ahead of sprint planning Discuss and document BF/FE integration topics on the Concord dev slack channel. Establish a meeting for BE/FE for thinking :-)

Diligent with migration scripts: Schema comparison (Aqua Studio) Once the module released - do not add new functionality to it For any bugfix release we do UI and BE integration testing

@Oleksiy_Lemeshko to setup online party on developers day

Release: bump up interface version during development when there is a breaking change Release: Do not forget to mention SRS v4 release case on release retro boards Release: aim release deadline to Wed but not to Fri Release: bug fix release should contain bugfest JIRAs only

Try to highlevel estimate features in a smaller group (TBD) and review confirmed scope of a quarter with the whole team Do not forget to mention SRS v4 release case on release retro boards



@Oleksiy_Lemeshko to add a checklist to DoD to reflect acc-ty guidelines

Make 2 refinement sessions during 1 sprint as regular. Extra groomings should be discussed during sprint plannings.



For the backend stories - once you complete the story, in the comment section please provide details about requests and responses - https://folio-org.atlassian.net/browse/MDEXP-79 is a great example. This will help to review and close the story Add Fix versions when a story is closed Add user stories a day before planning session. If for some reason this is not possible and you end up writing a user story in the last minute please let PO know about it as soon as you can (even before you write them) so PO can adjust accordingly Sprint demo must happen before the sprint is closed. And we need a strategy of how this meeting needs to happen(it was our first meeting today). we can probably add demo tags while closing stories, to shortlist

@Oleksiy_Lemeshko to clean the board 1 day before the retro meeting min Discuss the backlog items that require reestimation during planning or during retro meeting. Reestimate (if needed) during planning. Add a comment to jira that will justify reestimation Check if recording can be turned off for retro

@Oleksiy_Lemeshko to pass Concorde team complements to CF team SM for him rto chare it with the team Active sprint backlog changes/amendments should be confirmed by PO Setup an internal demo to the team each sprint (make it as optional for the sprints with no system demo) Bigtests coverage support by the chages introducers Kruthi - to raise with MarkV and other Magda - to raise with Anton OL - with SMs

Prepare a list of JIRAs that we plan to review as a group at least a day before grooming so the whole team has time to prepare 5 SP for BE should be the biggest estimation (higher should be broken down) and 8 SPs for FE

Team to try to avoid cases with PRs that cover multiple tasks/stories

Determine and commit what are team Q1 deliverables
Sprint 78 Retro Board
Release activities should be reflected as technical US in sprint scope when applicable

Team members to raise the need of doing big amount of refactoring related to Jira items in hands

@Oleksiy_Lemeshko to check tech council meeting agenda to bring up "limits case" there team to continue working close with PO

@Viktor Soroka to raise discussion about huge PRs review approach on tech leads meeting


BE and FE integration misunderstandings should be taken offline without estimations given. @Oleksiy_Lemeshko as facilitator and @Viktor Sorokaas teamlead to moderate

Start internal demo practice (dry run)

@Oleksiy_Lemeshko and @Emma Boettcher to ensure during planning that any spike has clear goals defined in it @Dmytro Popov to prepare forecast for BE velocity by the end of sprint 70 @Oleksiy_Lemeshko to raise this case during SoS @Emma Boettcher a to have it discussed with Cate

Ensure cross team cooperation in terms of PRs review (Vega so far, other teams in future).

@Dmytro Popov to set up KT session from respectful developer to get better understanding of inter-module architecture @Emma Boettcher to maintain product backlog considering possible stories overlappping and checking if stories on top of backlog are actual. @Oleksiy_Lemeshko to facilitate planning sessions with walkthrough sprint backlog items before sprint start

Developers to mention during stand-ups that they expect some input from PO in a certain JIRA ticker. @Oleksiy_Lemeshko and @Viktor Soroka @Emma Boettcher to confirm that raised query is in hands

@Oleksiy_Lemeshko to flip planning pocker cards duringg stories estimation BE PR review should be promoted in CoreFunctional team if needed

@Oleksiy_Lemeshko to change retro format to What Went Well / What Should be Improved @Oleksiy_Lemeshko to facilitate refinement sessions more proactively