Skip to content

Project Management

Jump to bottom
Evan Mattson edited this page Jan 4, 2023 · 44 revisions

Tooling

We use ZenHub to manage Site Kit project which is publicly available to everyone. Viewing all phases of project management is as simple as installing the ZenHub browser extension or using the ZenHub app.

Kanban boards

ZenHub boards are used to manage issue life cycles.

Execution board

The Execution board covers the pipeline the issues go through during the definition and execution phases. This board contains the following columns:

  • Triage
  • Stalled
  • Backlog
  • Acceptance Criteria
  • Implementation Brief
  • Implementation Brief Review
  • Execution Backlog
  • Execution
  • Code Review
  • Merge Review
  • QA
  • Approval

Escalation board

The Escalation boards covers the pipeline which issues go through when potential bugs need to be reproduced. The board contains the following columns:

  • Triage
  • Escalation L0
  • Escalation L1
  • Remediation

Managing (sub)status

We use the assignment field to flag the "To do", "In Progress" status and move an issue to the next column when it is “Done”. Here is a typical example of the flow:

  1. To Do: issues which are "To do" in any of the project column are "unassigned"
  2. In Progress: issues which are "In Progress" in any of the project column are "assigned"
  3. Done: issues which are "Done" in any of the project column move to the next column and "unassigned" (assignment is removed)
  4. The cycle in the next column starts over

Managing sprints

Sprints are managed using GitHub milestones.

Managing releases

Releases are managed using ZenHub releases (refer to releases documentation).

Estimates

Estimates are done using ZenHub agile points. As a reference, we've kickstarted point-to-time allocation below until we move to velocity-based sprint capacity:

Points Hours
1 0 - 1
3 1 - 3
7 4 - 7
11 8 - 11
15 11 - 15
19 16 - 19
30 20+

Labels

The labels below are utilized to categorize issues:

  • Type: {type} the issue type (eg. Bug, Enhancement, Feature, Infrastructure, Support, Task)
  • P{priority} the priority of the task (eg. 0, 1, 2) – zero being the highest
  • Group: {category} the category of an issue (eg. Escalation)
  • Module: {module} the module a ticket relates to (eg. AdSense, Analytics)

Epics

Epics are used to categorize groups of issues that are related to a common goal/body of work.

Life of an issue

IMPORTANT: We use GitHub issues to track all task, therefore PRs should only be associated with an issue, not assigned a label, project, and/or milestone.

Triage

The GitHub issues view serves as the “Awaiting Triage” backlog.

  1. An issue is created.
  2. The issue “Type” label is assigned.

Issue cycle by type

Type: Bug, Enhancement, Feature, Infrastructure, Support, Task

Execution

Step
Task		                                   
Role
1. An issue requiring work is added to the Execution project board (automatically added to Triage column). Product Manager
Program Manager
2. The issue is then triaged and assigned a "Priority". As part of the triage process, issues are moved to Backlog if it is to be actioned within the current quarter, or moved to Stalled if it is not realistic to work on within 6 months from now. Product Manager
Program Manager
Lead Engineer
3. From the Backlog column, issues which are eligible to worked on next are moved to the Acceptance Criteria column Product Manager
Program Manager
Lead Engineer
4. “Acceptance Criteria” are added to the issue's description, and the issue is moved to the Implementation Brief column. Product Manager
Lead Engineer
5. The issue is (self-)assigned while the “Implementation Brief” is added to the issue's description. The issue is assigned an estimate and moved to the Implementation Brief Review column and unassigned. Engineer
6. The issue is (self-)assigned while the “Implementation Brief” is reviewed and the issue is moved to the Execution Backlog column upon approval. The issue is moved back to the Implementation Brief column if changes to the “Implementation Brief” are requested. In either case, the issue is unassigned. Lead Engineer
7. Once selected for the next sprint, the issue is assigned to the appropriate Sprint”. Project Manager
8. Once work commences on an issue, it is moved to the Execution column and is (self-)assigned by an engineer. A PR is created, following the Branching Strategy. The PR must contain details for each section predefined in the PR template, with a reference to the associated issue. The "QA Brief" section of the associated issue's description is populated and the issue is moved to the “Code Review” column and unassigned once development is completed.
IMPORTANT: Do not add GitHub keywords which would automatically close an issue once the PR is merged. 		Engineer
9. The issue is (self-)assigned while being code reviewed in the referred PR. The reviewer must ensure that the “Acceptance Criteria” are satisfied by the implementation and an appropriate "QA Brief" is provided before moving the issue forward.
Reviewers without merge-review capability should move the issue forward to the Merge Review column and the issue is unassigned.
Reviewers with merge-review capability may merge the PR and move the issue to the QA column.		 Lead Engineer
Engineer
10. An issue in the Merge Review column is (self-)assigned while being merge-reviewed in the referred PR. The issue is unassigned and moved to the QA column once the review is completed and the PR is approved and merged. Lead Engineer
11. The issue is (self-)assigned while being QA'ed and moved to the Approval column once QA is passed and unassigned.
If changes are required, the issue is reassigned to the engineer who authored the last PR and moved back to the Execution column where the cycle is repeated from this column onwards.		 QA Specialist
12. The issue goes through a final review and closed once approved or moved back to the Execution column where the cycle is repeated from this column onwards. Product Manager
13. The issue is closed. Product Manager

Type: Escalation

Escalation

Step
Task		                                   
Role
1. An issue requiring escalation is added to the Escalation project board by adding the Group: Escalation label. Support Specialist
2. The issue is (self-)assigned, moved to the Escalation L0 column (if previously in Triage), and then tested to be reproduced.
As a general rule, no more than 1 hour should be spent before escalating.
If not reproduced, the issue is unassigned and moved to the Escalation L1 column.		 Support Specialist
3. The issue is (self-)assigned and tested to be reproduced.
As a general rule, no more than 1 hour should be spent before escalating.
If not reproduced, the issue is assigned to a Lead Engineer for a final decision.		 Engineer

If at any time the issue is able to be consistently reproduced, a summary of the findings should be posted to the issue as a comment and the issue is then moved to the Remediation column of the Escalation board. The same issue should then be further defined according to the workflows of the Execution board. The team member facilitating the escalation should then notifiy the engineering team of the new issue which is ready for further action.

Clone this wiki locally