PM Guide
Hey, thanks for volunteering to be a PM on Access the Data. We really believe in the power of data and its ability to assist communities working towards equity. Huzzah for activism!
This document has been written to help serve as a resource for PMs specifically working on Access the Data. It is important to note that no two projects are alike, and you will not manage two projects exactly the same.
That being said, welcome! And here’s what you need to know.
- MAIN DUTIES
- TEAM LAYOUT
- TOOLS
- RESOURCES
At the time of this writing, the PMs meet every Monday at 5pm PT. We try to keep meetings to 50 minutes or less. The agenda for these meetings can be found here.
The primary duties the PM team performs are:
1.1 Managing Work
1.2 Project Planning
1.3 Managing Meetings
1.4 Managing the Team
1.1.1 GitHub and the Kanban Board
1.1.2 Creating issues
1.1.3 Closing Issues
1.1.4 Issue Templates
Every project at Hack for LA is managed on GitHub. GitHub is a software development platform. Users can set up a working environment, called a Repository, or Repo for short, where they can post the code they are developing for a program. Other programmers can view their code and make comments or even make adjustments or contributions to their code.
Developers are not the only people who can use GitHub, though. GitHub also offers a project board function, also called a Kanban. In its simplest form, a Kanban is a layout of all work that needs to be done, that is currently being worked on, and that is complete. Here is what a very basic Kanban looks like:
You will notice there are boxes inside of those columns with work that needs to get done. In GitHub, these tasks are called Issues. Outside of GitHub you may hear people use the term ticket or even user story. All of these things basically mean the same thing, it is a description of some work that needs to get done.
What the Kanban board looks like will be different on any project you work on. For Access the Data, we have one board with multiple views. Each view has different issues, filtered based on one or more criterion.
For the Website Kanban we have seven columns:
- Documents
- New Issue Approval
- New User Story Approval
- Prioritized Backlog
- In Progress
- Done
- Ice Box
The Documents column is where we put project oriented documents and information so they are easily accessed for the team. This includes our semester goals, resource links, and our current team.
The New Issue Approval column is where new issues automatically go after being created. We’ll talk about how to create issues in a bit. Issues in this column need to be reviewed by a PM to see if the task is well defined enough to be worked on. If it is, the PM needs to move the issue either to the Prioritized Backlog or the Ice Box.
The New User Story Approval column is where new user stories go after being created.
The Prioritized Backlog is where all tasks ready to be assigned live.
When an issue has been assigned to someone, it goes into the In Progress column.
When an issue has been completed, the PM will make a note at the bottom of the issue and hit the “Close” button. This automatically moves the issue into the Done column.
If an issue requires that another issue be complete before work can start, those prior issues are considered dependencies. When an issue is waiting on dependencies to be complete, the issue goes into the Ice Box column.
For a more in-depth information check out the (draft) Hack for LA Kanban guide.
There are a couple different ways to create an issue in GitHub.
First way is through the main repo page Issues > New Issue > Blank Issue - Get Started
Then...
Then...
Second way is if you have an issue open already and want to open a new one, for example, if you have the agenda issue open:
Once you have a new blank issue open, this is what it looks like:
Creating a blank issue comes with a template for you to fill in. It may be a good idea to take a look at other issues currently being worked on to better understand how we are writing issues.
You’ll notice that the headings of each section start with ###. That is because it is written in markdown. Oh, but not just any markdown, it is a special GitHub Flavored Markdown (GFM). If you are not familiar with any kind of coding, fear not, you will catch on quickly. There are formatting buttons on top to help you out but here is the syntax (coding grammar) for making different sizes:
If this seems fun and interesting to you click here to follow the rabbit down the hole.
Once you have given your issue a descriptive title and filled in the information on what work needs to be done, you will need to fill out the metadata of the issue. Let’s take a closer look at the right side column of the issue:
Don’t worry about milestones right now, we are not using them for the project MVP as we are still in an exploratory space.
There are two main reasons to close an issue:
- It is complete
- It is no longer work that needs to be done
When either happens, we need to close the issue. Only repo admins and issue creators are permitted to close an issue on GitHub. Admin access is given to PMs and leads. At the end of every issue there is a comment box with a Close issue button and a little dropdown of close options.
If the issue is complete, leave a comment and CLOSE AS COMPLETED.
If the issue is no longer needed, leave a comment why and CLOSE AS NOT PLANNED.
There are some processes and tasks that we do a lot of, such as onboarding and offboarding. To save ourselves the time of having to think through everything that needs to happen, we use templates for creating those issues. Here is the path to the templates:
Issues > New issue
Sometimes a process we do changes a bit and we have to update one of the templates. Or maybe we find ourselves doing a lot of something so we want to create a new template. Here are the steps:
Shortcut: here is a template that lists out all of these steps.
- Locate the issue
- Go to settings
- scroll to Features > Issues
- Click "Set up template"
If you are UPDATING an issue:
2. Locate the template you want to update
- Click "Preview and edit"
- Click the pen icon to edit
- make edits
- “x” out of edit mode and make sure everything looks correct
- Scroll up and click “Propose changes
- Make a note about changes that were made and click “Commit changes”
If you are CREATING an issue:
2. Create the issue
- Scroll down and click “Add template: select” > “Custom template”
- Click “Preview and edit”
- Click the pen icon to edit
- add as much information for the template as you feel will be consistent across this common process, including what labels will always be needed
- “x” out of edit mode and make sure everything looks correct
- Scroll up and click “Propose changes
- Make a note about changes that were made and click “Commit changes”
1.2.1 Onesheet / roadmapping
1.2.2 Running retrospectives
1.2.3 Planning "sprints"
1.2.4 Updating project information
A roadmap is a document that outlines, generally, when certain milestones of a project are going to be. What this looks like will be different anywhere you go, and require regular maintenance. However, no one is at Hack for LA full-time so we use a much more simple tool: a one sheet. Here is the 2023 semester one AtD one sheet as an example.
As you can see, it includes:
- the logo
- website address (which as of writing this is our GitHub README)
- project overview
- MVP milestones (I know, I said we are not using milestones but these are very abstract)
- Six-month roadmap
This little bullet point list is our roadmap, and it outlines our plans for the semester and needs to be updated every six months. Every January and July, we need to
- Update these goals in AtD Google Drive
- Replace the old one sheet for the new one on the Hack for LA product one master list
- Update the AtD project page by creating a ticket for VRMS
The first week of each month at Hack for LA is Planning Week. During planning week, Hack for LA does not conduct regular Community of Practice meetings, and projects do not hold their normal weekly meetings. What we do instead is run a retrospective. A retrospective is a team exercise where we evaluate how the project is going and what changes need to be made.
A popular format for retrospectives is START, STOP, CONTINUE. This is the format we use (but it doesn’t always have to be) and we run the exercise on a Google Jamboard. It looks like this:
This template can be found here. An example of a filled-out exercise can be found here.
The Jamboard allows everyone to edit the board at once with the tools listed on the left. Feel free to play around with these if you are unfamiliar with Jamboard, but the only ones needed for the retrospective exercise is ‘sticky note’ and ’pen’.
Note: We’ve tried using the Zoom whiteboard but there seems to be technical issues that pop up for different Operating System users, so we stick to Jamboard.
Before the meeting, make sure you
- Let the team know the regular meeting will be a retrospective exercise.
- Create a copy of the template and label it with the date of the exercise.
- Include a link to the jamboard in the agenda.
Here is an example of what the agenda for a retrospective exercise looks like.
At the meeting, you want to
- Briefly remind everyone what the semester goals are (from the One Sheet).
- Send a link in the chat to the jamboard so everyone is looking at it at the same time.
- Ask everyone to spend a few moments filling out sticky notes of thoughts they have on new things we need to try doing under START, things that are not working under STOP, and things we are doing that are working great under CONTINUE.
- When it looks like no more stickies are being posted, invite everyone to take a moment to review what everyone wrote and to put a little tick with the pen tool on any sticky note they feel warrants further discussion.
- When folx are done reading, go through the sticky notes that got the most ticks and discuss.
- Take notes in the agenda on any decisions that were made in the discussion and any Action Items that may have resulted.
After the meeting be sure to save and follow-up on any notes and action items.
Out in the world, you have probably heard of the term “sprints” in regards to the Scrum method of project management. Oftentimes, a sprint is a measurement of 1-4 weeks of work. Because we are working with volunteers it is hard to maintain that level of consistency. After all, most volunteers are working about 6 hours a week, including meetings. So a sprint setup is not super helpful. When people volunteer at the kitchen, they just want you to give them an apron and a ladle. So our planning needs to be about making aprons and ladles.
Every Wednesday when we meet, we look at the current issues, discuss where we are on the project, and determine what needs to happen next.
One of the most important tasks of the PM is to make sure that project information is up to date wherever it is published and well communicated. Here is the normal maintenance plan:
One sheets (every six months)
- Google Drive
- Hack for LA product one master list
-
AtD project page (called the “Overview”)
- Need to create a ticket with VRMS
- AtD Wiki
Meeting times whenever there are changes to recurring meetings
- In the calendar (duh)
-
AtD project page
- Log onto https://www.vrms.io/
- Click “Projects” at the top (it looks like a heading, not a button, I don’t know why)
- Click “ACCESS THE DATA”
- Scroll to the bottom and either edit a meeting or “Create new event” If you are having issues logging in, check out the VRMS guide on editing meeting times.
1.3.1 Scheduling
1.3.2 Agendas
1.3.3 Leading Meetings
Logging into [email protected]
To access the calendar you will need to log into the [email protected] Google account. To log in you will first need to log into 1Password to get the credentials to log into the AtD Google account. There, you will find the username, password, and authentication code. All accounts at HfLA use two factor authorization and the code to get into the account changes every 30 seconds. It looks like this:
Scheduling a meeting
Once you are in the account, you can go to calendar.google.com to view the calendar. Just click on the day you want to create a meeting for and edit the details of time, link to agenda if there is one, and who the invitees are. For one-off meetings it is totally ok to use a Google Meet room.
PLEASE AVOID SCHEDULING FULL-BLOCK MEETINGS. That is to say, please schedule 50 minute meetings instead of 1 hour meetings, and 25 minute meetings instead of 30 minutes. People need breathing room between meetings and we strive to have a culture of respecting others’ time on this project.
Scheduling recurring meetings
Recurring meetings are a bit more involved, so I will list out steps for this:
- Poll the team to see what the best suitable time is for this new recurring meeting
- Schedule in Zoom:
- Check the Zoom assignment spreadsheet to see which room is available for that time (some times may be very difficult to find)
- Update the spreadsheet with the new recurring meeting information
- Log into that Zoom account (you may need to access that Zoom rooms Google account with information on 1Password)
- Click Meetings > + Schedule a Meeting
- Fill in topic as “AtD - [name of team/function, ie Research]”
- Fill in
- When
- Duration
- Check box for ‘Recurring’ and fill in those details
- Save
- Scroll to the bottom and click “Copy Invitation”, and then copy from “Join Zoom Meeting” down
- Create calendar entry and invites
- Log into [email protected] Google account and go to calendar.google.com
- Schedule a meeting as described above in the previous section, but click the dropdown arrow where it says “does not repeat” and update it to say what cadence you need
- Paste the Zoom info in the description below whatever other meeting notes you might have
- [side-note] For extra points, save the meeting BEFORE adding anyone to the invite. Go through the rest of the year and remove any of the meetings that overlap with scheduled holidays and days off. This way, you won’t have to cancel meetings, they will already not be on the calendar.
- Then add invitees and send
- Update the cadence information as described above
All agendas are kept as issues on GitHub on the AtD Project Management Kanban. Navigation is GitHub > Projects > ATD Project Management > On-Going items. You can look at either the PM or All Team agendas to see how agendas are structured. If there is a meeting with the whole team, it gets put under onto the All Team agenda, be it a retrospective or demo day or regular weekly meeting.
Please look to these as templates if you need to start another agenda issue. A new issue should be made if it is a meeting for a different team or if it is a new year. At the beginning of the year it is a good idea to start a new issue for the team meetings as they can get quite lengthy.
Some good hygiene tips for creating agenda issues is to add an “agenda” label and to add a link at the top of the issue to the most recent agenda.
Leading meetings can be intimidating at first, but if you plan well enough and foster good collaboration you'll be confident and running meetings like a champ in no time!
Here are some tips:
- Be prepared - make sure there is an agenda ready and that all expectations have been communicated to the team via email invite and agenda issue.
- Remind the team on Slack of the meeting a few minutes before and share a link to the Zoom room.
- Make sure everyone has an opportunity to participate. If there is a discussion and someone has been largely quiet, ask them what their opinion on the matter is.
- Make sure one topic isn't dwelled on for too long, everyone has issues they are working on. If a topic seems important enough to spend significant time on, suggest to the team that a separate meeting be scheduled to address it.
- TRY TO KEEP TO 50 MINUTES OR LESS. A lot of meetings get put back-to-back and people appreciate it when they can breathe a little between.
1.4.1 Onboarding/offboarding
1.4.2 Posting open roles
Even though there is a process for getting people onboarded onto Hack for LA, we still need to onboard them to the project as well. This process can be time consuming, so be sure that when someone shows an interest that you talk to them beforehand to see if it is worth the time and effort to go through this process with them. It's frustrating when you onboard someone and they never show up to meetings. So get some face time in with them first and ask:
- What kind of time commitments can you make to this project?
- How long do you intend to volunteer for?
- Why are you interested in THIS project in particular?
To help move this process along more swiftly here are some issue templates for onboarding and offboarding people.
Onbaord PM | Onboard Developer | Onboard UX/UI
Offboard PM | Offboard Developer | Offboard UX/UI
There are two places we post open roles for Access the Data:
- The Open Roles wiki
- The HfLA: Open Roles board
To create a posting in the AtD Open Roles wiki, navigate to the wiki and click the edit button. Use this example for what needs to be in there:
Next you will want to post on Open Role card on the HfLA: Open Roles board. The project volunteers come from the various Hack for LA Communities of Practice. Here are shortcuts to all of the open roles, filtered by the community of practice:
UX/UI Design
UX/UI Research
UX/UI Writing
Product Management
Ops
Marketing
Data Science
Engineering
Go to the Recruit volunteers for team open roles issue and follow the instructions.
A further step you can take is to go onto Community of Practice (CoP) channels for whichever role you need and ask if anyone there is looking for a volunteer opportunity. The community leads may even be able to direct you to someone they know is not working on a project.
When you get a 'bite' meet up with the potential volunteer to
- Give them some background on the project
- Make sure they are capable of the work needed
- See if they can commit to at least 6 hours a week
- See if they can commit to at least 6 month on the project or to the end of project if it will be less than 6 months.
If it's a good match, start up an onboarding issue and give them a tour of the project board. Some roles may require that they just observe meetings for a couple of weeks before they start making contributions.
If you have gotten to this far in the process and are feeling confident about your new recruit, got back to the open positions board and move your recruitment card from the role column to the 'filled' column.
This is how the Access the Data team is structured. This diagram is what the team looks like when we are “scaled up” with a larger team. As of writing this, we only have one person serving each function, so there is no one working under a lead.
Project Management:
- GitHub
- 1 Password
Communications:
- Slack
- Google Meet
Documentation:
- Google Drive
- GitHub Wiki
Meetings:
- Zoom
- Google Jamboard
Design:
- Figma
- MVP - Closed
- V1: Data Catalog - ON HOLD
- Domain Knowledge
- Research
- UX Writing Guide
- Site Design
- Software Development (redirects to CKAN repo)
- Operations Engineering (redirects to CKAN repo)
- PM Guide