Chair	Timekeeper	Note Taker
SC	ES	LC

Items from last retrospective

• items from last sprint left in same order- all good
• code reviews moved to Thursday - been finding it good
• More context and pictures in ticket headers, screenshots in release notes
  • packing release notes full of images felt impractical, put links instead
  • image added to ticket header by developer before putting it into review
  • image will be on the branch you're working on

Items from the current retrospective

Looking at ISIS beam status page at standup in cycle

• a lot of time beam is off without us realising
• will give us context for the day with regards to possible scheduling
• could make just a PV on our dashboard, if you want more news look at the teams channel
• push back about adding another check to morning standup instead of keeping an eye on teams

Ticket context

• Want bad examples of tickets, action on ES for this
• Will bring this up again next retro
• Should we have a longer planning meeting to properly go over what a ticket would entail, and make sure it is written properly with correct acceptance criteria?
  • Will run into problem where "the person whose domain this ticket belongs to" is absent
  • This was something we used to do a bit of in pre-planning
  • Is it worth recording planning meetings so we can reference the discussion later (timekeeper)
  • Possibly have a note-taker for planning, will try it in next planning

Ordering the priority columns in planning

• People seem to pick up the tickets that they feel able to do/interested in
• Position in ready does (or at least should) influence order tickets are taken
• Feeling that it may not matter too much with 6-monthly releases, however patches change this
• Prioritising adds more time to talking about tickets, however planning meetings are already very short
• Sometimes people skip tickets because it's in an area they aren't familiar enough with, or is not clear what needs to be done
• Enforcing the order will push people into areas they're not comfortable, which would be good in the long term
  • We're allowed to make mistakes, you don't have to succeed from the outset (especially if it isn't urgent)

Splitting PM duties

• KB to split duties with GR

Make sure flash reviews don;t get missed

• track on github, flash reviews column on task board
• checking the teams channel on Monday is good, but there's a chance tickets get buried

Finding out tickets aren't needed

• this has happened in the past, we try our best, sometimes we are given incorrect information
• When picking up a ticket, verify with scientists what exactly they want for it (add this to the dev wiki)
  • Alternatively contact relevant sample environment team

standup length

• keep it to fewer points
• keep engaged during checking of tests/instrument health

github actions

• might be useful instead of jenkins builds
• spin up a windows environment for us
• started looking into a few, can be difficult
• where it's easy, try it, run it in parallel with existing builds, turn of the jenkins versions when no longer needed
• wiki check might be easy enough to move
  • Friday ticket to do this
  • KB already trying to move project board checks
• not sure if we can have project level actions
  • actions are repo level, org level we'd need an app, however we can make our own (KB already trying this)

Mad sad glad

• LJ Friday went well, had both meetings, interesting tickets, completed in time
• SC glad he tried programming elsewhere in EPICS
  • Some OPI standards were difficult to find, in fact most hidden in checker script
  • we don't have a standards page, but we do have an example template OPI we should use
  • perhaps make a Friday ticket to make the checker script more clearer
• ZK glad about description of the ticket that didn't end up being needed
• ZK glad SC bringing new tools into the meeting
  • happy to try it, but many of us unsure about its used