2024-04-03

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