Participants


Retro Points

Some things to think about:

  1. What did we do well, that if we don’t discuss we might forget?
  2. What did we learn?
  3. What should we do differently next time?
  4. What still puzzles us?
  5. Which tools or techniques proved to be useful? Which not?
  6. What is our biggest impediment?
  7. If we could change 1 thing, what would it be?
  8. What caused the problems that we had recently?
  9. Which things went smoothly? Which didn’t?


Retro Summary

Actions from last retro

See Actions: CPS Retro - 09/04/2024

OwnerAction ItemNotesTeam Rating (star)

David Donnelly 

To raise lack of access for CPS team on E code or environment

  • same as before: no access given yet but for the last performance bug , Priyank Maheshwari were able to work and collaborate with the E team via screen sharing and for the given problem it has worked as a good solution
(star)

(Escalation) To communicate with E to define roles/responsibilities in terms of epics/stories/prioritization decision making .


needs to be followed up for the next retro

---
Kolawole Adebisi-Adeolokun 

Meeting/Workshop with E. to have an understanding and know their set up for tests  KPI

Done - Team and E had a workshop to discuss this(star)

Daniel Hanrahan 

Bug acceptance criteria meeting

Done 

(star)

Cross team meeting on new way of implementing user story breakdown

needs to be followed up for the next retro

---

TEAM

Toine Siebelink 

David McWeeney 

Lee Anjella Macabuhay 

Halil Cakal 

Gerard Nugent 

Sourabh Sourabh 

Sean Beirne 

Priyank Maheshwari 

Daniel Hanrahan 

Levente Csanyi 

ALWAYS COMMENT if you have looked at a code - do state you reviewed and no
comments.

This has been working fine as commits are reviewed early and quicker than before

(star)

Pair Programming-  call these as needed

Be open to it, aware its an option

Example - if lots of comments on a code review

- call a pair programming session.

This has also been more used since last retro i.e. priyank and lee anjella for subscription

(star)

Submitter should know the 3 reviewers on a review - and call the priority OK to ask people for code review - especially if urgent (i.e to get review same

  • Applied by team members and working very well 
(star)


What went well???

What can we do better???


Actions

OwnerActionNotesDue Date

David Donnelly 

(Escalation) To communicate with E to define roles/responsibilities in terms of epics/stories/prioritization decision making .


Action from last retroNext retro

Daniel Hanrahan 


Cross team meeting on new way of implementing user story breakdown

Action from last retroNext retro

Clarify names on the tests (i.e. Integration tests) and create guidance for team


Next retro

TEAM

Toine Siebelink 

David McWeeney 

Lee Anjella Macabuhay 

Halil Cakal 

Gerard Nugent 

Sourabh Sourabh 

Sean Beirne 

Priyank Maheshwari 

Daniel Hanrahan 

Levente Csanyi 



On user stories - 

  • (E) be clear on acceptance criterias before starting especially when working with bugs
  • use right level of Jira creation i.e. 'user stories' 'sub tasks'
  • description on Gerrit for code reviews

Recurring

On bugs -

say 'NO' more often especially when there is not enough information!


Recurring

On release notes -

Update release notes with commits if possible

  • Note to add it on acceptance criteria (if it makes sense)

Recurring


Call outs

Next Retro Date:

 





  • No labels