Project Management
Project management is more than its literal interpretation. It included assigning accountability, trust, motivation, and respect to those you give the tasks to. By giving the engineer accountability with their project. They are more likely to see it through to its deployment as well as encourage other engineers to solve their issues in a healthy and team-oriented way. This also opens the door for the engineer to request PRs from other engineers that have already worked on their specific project.
Project Preparation
In order for a project to get done, one must first understand what is being asked to be done. This is where project preparation comes in.
- Map out to-do list in broad strokes
- Update description with Epic Description & Technical Notes
- Assign and prep team
- Create tickets from to-do list or enlist the engineers to create their own tickets to achieve project goal
- Add agreed upon est. release date to project hours spreadsheet
- Inform Product of estimated release date
- Set up Slack date reminder(s)
Dev Allocation
In order to compartmentalize issues and projects, it is suggested to split engineers off into small and manageable groups. The number of groups depends upon the needs of organization along with amount of engineers available at that time. In addition, it is wise to create a group that is continuously focused on defeating bugs and working on miscellaneous tickets.
Currently, creating engineering groups follow this naming convention:
- engineering-group-n
Note: If the work for a project requires more than two engineers (which should be avoided) a new channel in Slack should be created for easier communication flow between groups.
For example:
#engineering-project-name
Dev Allocation Sheet
A developer allocation file in Airtable should be created to track what project each group and engineer are focused on. This makes it extremely easy to manage workload and increase engineer performance. Here is an example of what a couple rows would look like:
| Engineer | Group # | Focus | In Progress | On Deck | In The Hole |
|---|---|---|---|---|---|
| Mark Hamill | 1 | Bugs/Misc | API Tests | Form Utilities | N/A |
| Daisy Ridley | 1 | Bugs/Misc | Database Restructuring | Form Erasure Bug | Auth Refactoring |
Project Preparation
In order for a project to get done, one must first understand what is being asked to be done. This is where project preparation comes in.
Generally, you want to create a document in Google Docs that lists out the steps that you need to take to complete the project assigned to your engineering team. This includes, but is not limited to:
- Map out to-do list in broad strokes
- Update description with Epic Description & Technical Notes
- Create tickets from to-do list
- Assign and prep team
- Add agreed upon est. release date to tracking spreadsheet
- Inform Product of estimated release date
- Set up Slack date reminder(s)
- Add Check-in calendar reminder(s)
- Set up “In Progress” checklist
Issues vs Epics
Corralling specific issues into one area is recommended if the size of the project is larger than one specific issue. To do this, ZenHub offers a feature called an Epic.
To be brief, it contains multiple tickets that are all working towards the completion of a feature. It goes without saying that this is a major help when working on larger projects with multiple areas that need to be worked on.
One may ask:
"What if the ticket I have is an issue, but requires multiple areas to work on to fix?"
To that we say, if the issue spans multiple areas or requires multiple engineers to address, it should be considered an Epic.
New Issues vs Backlog
During the beginning phases of using ZenHub, there may be some confusion between where to place certain tickets. One of such may be New issues and Backlog. Here we will clarify the differences between the two:
New Issues should be taken literally. They are new issues that have been created by product or introduced as new projects by engineering management. These issues are then assigned to specific engineers and placed in the In Progress Swim Lane.
When an issue can't be completed either by a blocking ticket, or a change in priorities, it is moved from its current Swim Lane to Backlog. Here the issue will stay until there is enough progress done for it to be moved to In Progress and eventually completed.