...
Note: to tag a person, use the @ symbol and select begin to type their name.
...
Selecting Tickets
Helpful Jira views
...
New bug reports: https://archivesspace.atlassian.net/secure/RapidBoard.jspa?rapidView=15
New feature requests: https://archivesspace.atlassian.net/secure/RapidBoard.jspa?rapidView=16
The Dashboard shows the latest activity in Jira and also provides a quick overview of tags
...
When tickets are first made, their status is “Newly Added.” The Program Manager will make the first pass at vetting tickets, mostly making sure that institution-specific support requests don’t end up in our queues. Dev. Pri. looks at the Awaiting Prioritization and Awaiting more Information queues. Have a mix of both.
Caution: Awaiting more Information queues can become a “purgatory” if the reporter or other people don’t provide more information. It may be worth doing a scoped search to devote a few meetings to the Awaiting More Info tickets to close unresponsive tickets.
Look at the priority symbols on the cards, but don’t on this too much. Keep in mind that priority is a subjective ranking, which should be reassessed as part of the meeting discussion.
Note: Lydia Tang changed the default priority to “minor” in 2019. Previously, the default was “major.” Take both statuses with a grain of salt.
Selecting tickets by themes can be fun and also helpful to making sure that tickets compliment and don’t conflict in recommendations
Assigning Tickets
Ask team members to add any strengths/interests to the roster. Members with technical coding expertise and or cataloging expertise are especially important to note. If expertise in these areas (or others) are not on the team, be sure to prepare a slate of tickets to share on the member list and potentially invite external experts or the original ticket reporter to discuss the tickets at the meetings.
...
Make sure to match tickets to expertise as much as possible.
Don’t assign more than 2 extremely involved/complicated tickets to a single person during a given month.
Laney and Lora are technically not a part of Dev. Pri. but are there for their expertise and feedback. Assign up to 2 tickets (1 each) to them only if their particular expertise is required.
This approach to “assign tickets” is only one way to do. Other possible arrangements could include having subteam members sign up to assign tickets for a given month. This actually might be a more equitable way to distribute the task and would succeed in involving the team more. This initial approach was done primarily to save the time of subteam members from trying to figure out how to select their own tickets each time. Regularly ask the subteam members for feedback on the approach and if they have other ideas.
Before the Meeting
A new agenda with ticket assignments should be sent out to the team shortly after a given meeting. This allows the team members a nearly full month to investigate their tickets.
...
The link to meeting agenda with ticket assignments
Ask that the team members add their notes before the meeting
Encourage team members to comment on the tickets ahead of the meeting if they have any questions, this way the ticker reporter or someone else can provide more information.
During the Meeting
Keep the meeting focused - Dev. Pri. needs to cover a lot of tickets. If discussion of a particular ticket is getting too bogged down, perhaps the ticket needs to be moved to “Awaiting More Info” and/or added to the next month’s meeting. Consider having a 5 minute limit for each ticket.
...
It may be worth considering alternating people when presenting tickets, as opposed to having a single person present all of their tickets at a time. Often, the team member would need to follow up on the ticket with a note, and it may be best to skip temporarily to someone else’s tickets while that team member leaves the follow-up text on their ticket.
Reassess the priority ranking and labels on tickets. Adding/clarifying labels on tickets can help the program team identify related tickets during a development sprint.
After the Meeting
The leader/co-leaders move the tickets on the board a few days after the Dev. Pri. meeting. This gives the subteam members time to comment and follow up on their tickets.
...
Sometimes it’s not possible for a ticket to move form one column to another. If that’s an issue, move the ticket first back to “Awaiting Prioritization” and try it again from that status.
TAC/UAC updates
Sample Council update:
Provide a statement on how many times Dev. Pri. met since the last update and how many tickets the team addressed (count on the Decisions column of each meeting agenda)
...
[list tickets needing larger group input]
Quarterly Board Reports
The Technical and User Advisory Council chairs will ask the Dev. Pri. leader(s) for reports to add to the council reports four times a year.
...
We look forward to continuing to meet on a monthly basis to continue to review and prioritize bug reports and feature requests
Generating Jira Reports
From one of the kanban board views, expand out of the side menus and click on “reports”
...
Reports for Average Age and Resolution Time might also be helpful. As one can see, tickets can take a long time to work through the system - hence it is important to be efficiently address a lot of ticket in each Dev. Pri. meeting.
...
Note: these reports may be sobering but can be helpful for visualizing the sheer amount of bug and feature requests that Dev. Pri. wades through.
Special Projects
Dev. Pri. may want to consider special projects that align with its mission including creating surveys, calls for feedback on selected tickets, or recommending Task Forces to address areas of need to Council leadership and the Program Manager.
...