2021-03-03

Items from last retrospective

  • Monday reviews are still working well

  • We’re better at being stricter for high/medium/low

  • We have now set general meetings to have alternative hosts

  • When systems tickets get added to review (mostly by CMS then they will be pointed based on expected review time)

  • Release notes PR system is still well liked

  • Games on Friday coffee has attracted more people, which is good

Items from this retrospective

New planning site

  • No need to add ticket numbers for each story when pointing

  • We should start the session afresh before each planning to stop phantom accounts hanging round

  • It’s ok not to have don’t-knows on the priority points

Why are some people quiet in pointing tickets etc

  • People have different communication styles

  • We should discuss estimates but it might be worth taking less time on wildly different estimates

  • Quieter people tend to be unsure and voting on gut reaction (which is fine) and feel like they learn more after the discussions

  • We will try the chair being the first person to input in the discussion of points

  • By missing out on the quieter people way may be losing the concept of how complex is it for the average developer

Adding flash reviews to release notes

  • If it’s a flash review that needs something in the release notes it’s probably not a flash review

  • Flash reviews were originally created to be process-light

  • We just did a large change in how we did release notes, we should see what users think about this first. Next release we should discuss

  • If reviewing a flash review and you think it’s very user facing then ask them to put in release notes

  • When we do the instrument demos we should ask what people think of the release notes

Spread of ticket sizes

  • Pair programming more would be good, we may be doing less of this remotely but it’s still happening

  • We could split tickets more but we’re pretty good at this

  • We should do more splitting up in an ad hoc way rather than up front as developers will know a bit more at that point

  • We should encourage newer developers to pick up big tickets too

  • We should ask at the end of planning if we have too many big tickets