Concorde retrospective board

Ongoing improvements

Team to start the practice of 2 PRs creation for US: business story functionality related code PR and code improvements related PR. Viktor Sorokaas TL to ensure this practice is followed where applicable
Team to start notifying team channel members about sick leave and beginning of the vacation in the slack
Oleksiy_Lemeshko to flip planning pocker cards duringg stories estimation
BE PR review should be promoted in CoreFunctional team if needed
Release activities should be reflected as technical US in sprint scope when applicable
Team to try to avoid cases with PRs that cover multiple tasks/stories
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
Active sprint backlog changes/amendments should be confirmed by PO
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
Sprint backlog items should be ordered during planning reflecting the sequence (if any) of implementation. (from S89)
Do not hesitate to speak up if you see any dependency during any meeting (from S89)
Consider an impact of BE changes to UI stories/bugs (from S89)
Q2 2020 release. Rules of engagement

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
Concorde sprint 104
Be more careful when estimating infra stories (RMB, etc)
Concorde sprint 103
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
Concorde sprint 101
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
Concorde sprint 100
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)
Concorde sprint 99

Concorde sprint 97
Concorde sprint 95
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 :-)
Concorde sprint 94
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
Concorde sprint 93
Oleksiy_Lemeshko to setup online party on developers day
Concorde sprint 92 & release retro
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
Sprint 91 Retro Board
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
Sprint 90 Retro Board

Sprint 89 Retro Board
Oleksiy_Lemeshko to add a checklist to DoD to reflect acc-ty guidelines
Sprint 88 Retro Board
Make 2 refinement sessions during 1 sprint as regular. Extra groomings should be discussed during sprint plannings.
Sprint 86 Retro Board

Sprint 85 Retro Board
For the backend stories - once you complete the story, in the comment section please provide details about requests and responses - MDEXP-79 - Getting issue details... STATUS 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
Sprint 84 Retro Board
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
Sprint 83 Retro Board
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
Sprint 82 Retro Board
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
Sprint 81 Retro Board
Team to try to avoid cases with PRs that cover multiple tasks/stories
Sprint 80 Retro Board
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
Sprint 77 Retro Board
Team members to raise the need of doing big amount of refactoring related to Jira items in hands
Sprint 75 Retro Board
Oleksiy_Lemeshko to check tech council meeting agenda to bring up "limits case" there team to continue working close with PO
Sprint 74 Retro Board
Viktor Soroka to raise discussion about huge PRs review approach on tech leads meeting
Sprint 73 Retro Board
Sprint 72 Retro Board
BE and FE integration misunderstandings should be taken offline without estimations given. Oleksiy_Lemeshko as facilitator and Viktor Sorokaas teamlead to moderate
Sprint 70 Retro Board
Start internal demo practice (dry run)
Sprint 69 Retro Board
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
Sprint 68 Retro Board
Ensure cross team cooperation in terms of PRs review (Vega so far, other teams in future).
Sprint 67 Retro Board
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
Sprint 66 Retro Board
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
Sprint 65 Retro Board
Oleksiy_Lemeshko to flip planning pocker cards duringg stories estimation BE PR review should be promoted in CoreFunctional team if needed
Sprint 64 Retro Board
Oleksiy_Lemeshko to change retro format to What Went Well / What Should be Improved Oleksiy_Lemeshko to facilitate refinement sessions more proactively

Browser not supported