-
Notifications
You must be signed in to change notification settings - Fork 2
Retrospective notes 2020.03.04
JamesKingWork edited this page Mar 5, 2020
·
9 revisions
Yes, this was missed after the last retrospective. Some combination of James, Kathryn and John to do.
- We are happy with what we have for the budget we have
- Floating licenses/more licenses will cost more
- Possible reasons:
- Lots of support tickets (1/3rd of the sprint)
- Lots of tickets leftover from EMU rush
- We are not extremely unhappy about this as we got a lot done, but it would be good to manage it better
Suggestion: To encourage throughput we prioritize reworks and reviews over current tickets as well as new tickets.
- Pros
- These reworks and reviews are likely a higher priority than our current ticket so it fits in with our prioritization
- It should encourage tickets to not hang around in ready and review and decreases their time from ready t complete
- May encourage people to document their progress more on a ticket when they are recording what they have done prior to switching to a rework
- Cons
- More context switching
- Switching state of a machine from one ticket to another takes time
Conclusion: This cannot be a blanket rule as there are many edge cases. For a sprint, we will try this. People should find a practical stopping point in their current ticket to do a rework if the situation arises. The metrics to decide on this will be: does everyone hate it? Has our throughput increased?
Should we create support tickets for all work for all instruments (SECI and IBEX) whether in cycle or not and whether we're contacted individually or not
Yes, within reason.
- The documentation is useful for future issues to create context
- It should be recorded as support, otherwise, it seems we are pulling in tickets without the proper process
- Helps to capture our effort
- Support is defined as: if a scientist needs help
- SECI tickets should be recorded only if they are of relevance to IBEX
- If a support call took very little time e.g. writing the ticket would take more time it may not be worth it
- It stops being time-effective or useful to others
- If a support call is one of a common theme we should record all them together as a tally to identify areas of the system we should improve