Using Jira in the AFL

If you haven’t used Jira before, check out the guides here. This general information will be critical to understanding the rest of the information in this Wiki.

The Advanced Fabrication Lab has a lot of projects going on at any given time, due to the large number of machines and different technologies present in the space. Jira is a tool which allows us to keep making progress on these projects and keep the AFL operating smoothly.

• Documentation
• Machine upgrades
• Workflow improvements
• Special Projects
• Staff Meetings

This is by no means an exhaustive list.

The AFL Project in Jira is quite large (over 250 issues in 2 years), so understanding how to find the relevant information can be a challenge. There are a few things to familiarize with in order to make this process easier.

Here are the major things to know:

• Kanban views: These are the ‘card’ views, and can be configured by the LC of the space
• Quick filters: These are displayed on each Kanban board, and can be configured by the LC of the space
• Epics: These are used to connect multiple issues that have similar tasks or work towards a larger objective
• Stories: These are issues that primarily document discussions, decisions or more nuanced topics such as research or information gathering
• Tasks: These are issues that are primarily “a thing that needs to be done”
• Sub-tasks: Can be created under Tasks to help break up the work

Configuration:

This view is the default, which is easiest to see issues across many different topics, people and stages of progress. Most suitable for project assignment or seeing high level priorities.

Configuration:

This view is easiest for AFL staff members to actually work on projects which are assigned to them. Simply scroll down to the correct person, and see all of their assigned issues that aren’t in the suspended, persistent or unassigned categories.

This view is also great for LCs to view progress and balance how much each staff member is working on.

Configuration:

This view is good to understand what current projects focus on. They are categorized by labels, so it is easier to tell if the focus is on documentation, training, organization, or something else.

This epic is used to connect all general staff meetings, including any training meetings that require note taking, and weekly meetings.

This epic is used to connect all meetings with FTEs or between LCs, which are primarily for high level tasks in the space.

This epic is used to connect all documentation related to any machine or product in the AFL.

This epic is used to connect all machine pricing and PaperCut related work in the AFL.

There are a few specific processes and steps for working on issues in the AFL.

Ask to work on an issue during a weekly meeting, or reach out to the LC of the space on Slack. Check out the “Unassigned” column to find a specific project that you would like to work on, or the LC will pick one for you.

Make sure to link whatever resources to the issue, so that all work can be tracked and reviewed when it comes time to do so. Update the status of the issue as often as is needed.

Log work to the issue as time is spent on them. Include quick notes about what you did and what needs to be done next. Include comments on the issue where appropriate, so that LCs or other reporters can quickly see what is being done.

If the issue hasn’t been broken down with objectives and deliverables, ask the LC or reporter for help on getting these written out in the description. Where appropriate, create sub-tasks and update time estimates.

Whenever work on an issue reaches a point of review, put it in the ready for review column by updating the status. If there is a specific set of things left to do, or that you would like to be reviewed, include that in the comments.

The reporter on the issue will try to review the work by the end of the week, and provide a comment on the work, either moving it back to “In-progress” or to “Completed” if the issue is done.

• Estimated work
• Reporter
• Labels
• Priority
• Description

Be sure that new issues are labelled correctly so that they can be properly organized.

Documentation: this label is pretty self-explanatory, but it covers any form of documentation we write for a special project i.e. Dozukis, SOPs, training packets

Labspace: this label should be tagged to an issue that involves the labs which wouldn’t be considered maintenance or upgrades. i.e. LPKF Table Setup, Moving Epilog

Procurement: This label should be tagged to any project that involves the need to purchase something, that way when the LCs need to go through and order items they can go to the search issues tab and search for the Procurement label.

Maintenance: another self-explanatory one, but any project which involves maintenance or upkeep on a machine or in the lab should have this tagged to it.

Upgrading: This label is reserved for projects which are clearly upgrades to the existing machines or setup that we already have and involves the addition of a new purchase. This label will almost always exist with the Procurement label.

Training: Any issue associated with training should have this label associated with it whether it is a training packet or the issue itself is a way of tracking trainees progress through their training.

Structure: This is probably the most confusing label because it doesn’t have to do with any physical structure but more the structuring of the hierarchical management system. An example is the SLM track development issue.

Meetings: I think this label is mostly used in the design team workflow but the same principle can carry over to the lab spaces. If you have a meeting, specifically with an outside client go ahead and tag the issue with this label.

Brainstorming: Another design team label, however we can use it to mark issues which are used as projects to think up ideas for new workshops, outreach, etc.