Project Management
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:
- dev-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:
#dev-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 increse 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.
- 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)
- Add new project to Dev Allocation Sheet
Project Estimation
When a project is assigned to an engineer or team of engineers, it is essential that the engineer(s) provide an ETA to feature deployment. In order to consolidate where projects are listed and detailed, we utilize a channel to organize all of the projects into an easily searchable, readable fashion called > #dev-projects
#Dev-Projects
This channel is reserved specifically for project estimations. Project estimations should be done promptly once assigned, preferably within a one to two day period and include the following:
- the date that the feature will be deployed
- the optimal date the feature will be deployed
- total hours that it will take to complete
- link to the feature's main ticket on
The total estimated hours and date given above are to be logged into a Google Sheet and will be used as a reference when reporting the KPIs of that project detailed below.
Date
The estimated date is used to track any changes in the estimated time to deployment. This includes potential delays as well as changes in the engineers assigned as well as logging any problems encountered with the feature.
Hours
The estimated hours act as an anchor get the percentage-to-completion for a project.
In order for this to work, engineers are asked to share their hours-worked at the end of each week for every project they have been assigned to. Their actual hours will then be calculated against the estimated hours to give the percentage of actual hours completed. This data will be used to assist in the feature's KPI; And as a side-effect, will track the efficacy and rate of improvement of engineers through time.
Jira Swim Lanes
Jira is an useful tool in which you will be able to track progress on a broad level. One of the main tools that Jira provides are its Swim Lanes.
Swim Lanes provide your organization with the context and progression tracking it needs by splitting up specific projects and tickets into multiple areas of development. You can name the Swim Lanes anything you want, but it is typical to name them as follows:
- New Issues
- Icebox
- Backlog
- In Progress
- Needs Review
- QA
- Staging
- Closed
Issues vs Epics
Corraling specific issues into one area is recommended if the size of the project is larger than one specific issue. To do this, Jira offers a feature called an Epic.
An Epic is a large body of work that can be broken down into a number of smaller stories, or sometimes called “Issues” in Jira. Epics often encompass multiple teams, on multiple projects, and can even be tracked on multiple boards.
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 Jira, 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.