Retrospective notes 2020.06.24 - ISISComputingGroup/ibex_developers_manual GitHub Wiki

Previous Retrospective

We should make a ticket to add to the project board checks that notifies us when a ticket has been in review for a week or more. Currently, the project board checks code is not in git.

The new method of running planning and pre-planning, where we point as we assign to high, seems to cut out a lot of duplicated discussions and lets us have shorter meetings.

Yes, we like this! 👍

Could we use the same password for all zoom meetings and have it included in the email?

This issue has been resolved by clicking the link. There are two passwords a numeric for the phone and a regular password.

Recording Architectural decisions

There was a discussion at the LabVIEW user group meeting today about documentation. One thing that was recommended as particularly useful by one contributor (and seemed interesting to me) was to keep architectural decision records (ADRs). We often meet to discuss things and make decisions but don't necessarily formalise the results so they can be tracked and easily located later. They might also have an audience in our user base and in training for future developers. i.e. why is it done like this?

https://github.com/joelparkerhenderson/architecture_decision_record

We have a decision log, which is being used more and more, and it is becoming useful. We should use a more solid template. The link above has some good ideas of how to layout this template.

Added tickets

John created an added tickets channel. Kevin has already been recording these added tickets. It is useful to be able to track which tickets have been added and why. Therefore we will create a label and people are expected to write on the ticket why it was bought in. John will remove the Teams channel.

We need to be aware of why we are adding tickets and we should only be doing this in discussion with others (especially those likely to disagree with us). We should also look out for patterns emerging with tickets being added in. If there is a pattern we need to plan to reduce the need to bring in tickets at the root, maybe something is not currently robust enough or we need to consider our planning further. To find this pattern we will need to look at the reasons for tickets being bought in and possibly flash reviews (though we do not want to add extra process to flash reviews as that is not their purpose).

How do we think the background phone call for tech debt day went?

Some felt it useful and enjoyed being connected with the team, others weren't so interested. If people wish to create it then on Friday afternoons they are encouraged to do so, making the idea become semi-regular. People don't have to join in if they do not want to.

We didn't get full participation in tech debt stand down. Why? Do we care?

We rarely ever get full participation. Some feel there was less this time around, others feel there was the same amount but different people were involved. We still believe it is above the threshold before we start to wonder if the days are worth it. People aren't obliged to join in, but it is a nice opportunity to work on something different.

Panning poker site vs zoom poll?

We prefer the site. The only issue being that the values don't match our scale. There are other sites we could look at though.

Microphone quality

Some people are difficult to hear in meetings due to low quality microphones. It is not always obvious to the person speaking. Thomas, Bish and Chris now have solutions or solutions are on their way. We can test out our own audio in Teams and Zoom. Dom is a dalek today.

EPIC tickets processes

We like Kathryn's suggestion:"I'd like to propose the following process, that should allow enough sanity for whoever is tracking the points, as well as being able to be worked with in a sensible fashion: the EPIC is added to proposals, we point and timebox against the EPIC. When the end of the timebox, or end of the sprint is reached - whichever comes first - points are assigned to the sub-tickets that were undertaken, the EPIC is sent back to the proposals column (if there is still work to do on it), the points value and timebox reference removed, as well as the face of whoever was working on it so that we aren't prejudiced for prioritisation. There is probably some refinement to this needed, but it might make it less painful for us to use them"

Only 3 tickets in review and only 1 of 4 tickets in ready were not reworks

Yes, we like this! 👍

Regular snapshots of the burn down graph are useful

Yes, this is really helpful to see! We don't want to end up chasing metrics though.

New style of release notes was very helpful during demos and drop-in sessions

Highlights and breaking changes sections are good! Make sure that the person doing the ticket writes it in a nice and verbose way. We should add writing the highlights and breaking changes into our processes.

Timings of the review meeting

Can we do a time per ticket in the review? Another suggestion is to put estimated times on the slide.

What we chose was to order the review slides by the longest time first. When someone puts their slide in they should insert in between one that they believe to be longer and one that they believe to be shorter.